Re: LSI mps(4) driver issues with PIKE 2008/IMR (LSI SAS2008)
On Thu, Mar 22, 2012 at 16:24:16 +0100, Jake Smith wrote:
Hello,
I am trying to get the latest mps(4) driver in FreeBSD 9-STABLE working
with am LSI SAS2008 variant from ASUS, they call it PIKE 2008/IMR. Link
http://www.asus.com/Server_Workstation/Accessories/PIKE_2008IMR/
From what I can see this card should be compatible with the mps(4)
driver MFC'd to 9-STABLE about 6 weeks ago.
# uname -a
FreeBSD xxx 9.0-STABLE FreeBSD 9.0-STABLE #3 r233304M: Thu Mar 22
12:53:17 GMT 2012 root@xxx:/usr/obj/usr/src/sys/GENERIC amd64
Revision: 233304
Initially the card is not seen at all by the driver, however pciconf
shows us why that is.
mps0@pci0:2:0:0:class=0x010700 card=0x843b1043 chip=0x00731000
rev=0x03 hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 9240'
class = mass storage
subclass = SAS
It seems on other models of LSI SAS2008 the chip device ID is 0x0072,
however for some reason this card has 0x0073. So I patched the mps(4)
driver and recompiled.
diff -ruN mps.orig/mpi/mpi2_cnfg.h mps/mpi/mpi2_cnfg.h
--- mps.orig/mpi/mpi2_cnfg.h 2012-03-22 14:50:53.0 +
+++ mps/mpi/mpi2_cnfg.h 2012-03-22 14:52:23.0 +
@@ -416,7 +416,8 @@
/* SAS */
#define MPI2_MFGPAGE_DEVID_SAS2004 (0x0070)
-#define MPI2_MFGPAGE_DEVID_SAS2008 (0x0072)
+#define MPI2_MFGPAGE_DEVID_SAS2008_1(0x0072)
+#define MPI2_MFGPAGE_DEVID_SAS2008_2(0x0073)
#define MPI2_MFGPAGE_DEVID_SAS2108_1(0x0074)
#define MPI2_MFGPAGE_DEVID_SAS2108_2(0x0076)
#define MPI2_MFGPAGE_DEVID_SAS2108_3(0x0077)
diff -ruN mps.orig/mps_pci.c mps/mps_pci.c
--- mps.orig/mps_pci.c2012-03-22 14:48:41.0 +
+++ mps/mps_pci.c 2012-03-22 14:51:59.0 +
@@ -99,7 +99,9 @@
} mps_identifiers[] = {
{ MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2004,
0x, 0x, 0, LSI SAS2004 },
- { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008,
+ { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_1,
+ 0x, 0x, 0, LSI SAS2008 },
+ { MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2008_2,
0x, 0x, 0, LSI SAS2008 },
{ MPI2_MFGPAGE_VENDORID_LSI, MPI2_MFGPAGE_DEVID_SAS2108_1,
0x, 0x, 0, LSI SAS2108 },
After reboot it now loads the mps(4) module and attempts to init the
card but fails.
# dmesg | grep mps
mps0: LSI SAS2008 port 0xd800-0xd8ff mem
0xfbd7c000-0xfbd7,0xfbdc-0xfbdf irq 16 at device 0.0 on pci2
mps0: Doorbell failed to activate
device_attach: mps0 attach returned 6
From this point I'm stuck on what to try next, google does not provide
any answers for this situation. Does any one have any advice or ideas as
to why this is not working?
I am able to provide ssh access to the server if any one wants to log
on and have a look at it.
In looking at the specs, that card supports RAID-5 and RAID-50. That means
it isn't a SAS card supported by mps(4), but rather a MegaRAID card.
It should be supported by mfi(4). Try adding the PCI ID to that
driver and see if that works. Or you can grab the driver from the
head_mfi branch, it looks like it already supports that card. Here's the
mfi_pci.c file, you can see the PCI ID in there:
http://svnweb.freebsd.org/base/projects/head_mfi/sys/dev/mfi/mfi_pci.c?revision=232888view=markup
Ken
--
Kenneth Merry
k...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: increasing dd disk to disk transfer rate
On Fri, Jan 13, 2006 at 08:13:00 +1100, Peter Jeremy wrote: On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Note that whilst increasing the DD blocksize will speed up the transfer, it will also increase the amount of collateral damage when a hard error occurs. If you rummage around the ports or tools tree, you'll find a utility (its name escapes me but I believe it was written by phk) that is designed to do disk-to-disk recovery - it copys data in big slabs until it gets an error and then works around the faulty area block by block. It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. I used it to copy a friend's hard drive, and it worked well. (Although the supposedly 'bad' disk didn't turn out to have any bad sectors.) Ken -- Kenneth Merry [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tracing Disk Access
On Mon, Nov 22, 2004 at 16:22:54 +0100, Hanspeter Roth wrote: Hello, I have set an idle timeout for the hard-disk. But when there is no user activity there are frequent disk accesses. How can one trace disk access? I'd like to know the kind of access and on which files/directories/ nodes. I'd like to log on the console or on a memory disk file. Well, this isn't quite what you want, but if you have a SCSI disk you can use the CAM debug facility to see what's going on. Compile your kernel with the CAMDEBUG option. Then run 'camcontrol debug -Ic bus:target:lun' where the bus, target and LUN are the numbers displayed by 'camcontrol devlist'. You'll see more console output than you care to see. (It'll printout the CDB for each command that goes down to that particular device.) If this disk contains /var/log, you'll get into an interesting loop because each console printf will cause syslog to write to the disk, which will in turn cause another console printf. Type 'camcontrol debug off' to turn it off. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bcm4400 driver and Dell 8500
On Wed, Aug 27, 2003 at 12:24:11 -0500, James Nobis wrote: On Wed, 27 Aug 2003, Joe Marcus Clarke wrote: On Wed, 2003-08-27 at 09:27, James Nobis wrote: On Wed, 27 Aug 2003, Kenneth D. Merry wrote: On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote: Hello James and Ken, Both of you are having real problems with the bcm driver and both of you have a Dell 8500. This is James' dmesg output, which from memory looks very similar to your Ken? bcm0: Broadcom 10/100 Base-T Ethernet mem 0xfaffe000-0xfaff irq 11 at device 0.0 on pci2 bcm0: Ethernet address: ff:ff:ff:ff:ff:ff panic: bcm0: Strange type for core 0x Yep, the messages I get are identical when I load it as a module. I'm running 5.1-current from august 22nd. I can try pulling down the latest 5.1 tommorow if you think this might help. This is the same result as when I tried the driver from over a month ago. We think that the problem is something to do with the PCI configuration of the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the memory map is not right. Before sending this email I was going to obtain a backtrace. I recompiled with the symbol table and kernel debugger and now the driver appears to work fine. Should it work this way? Hmm interesting. Ken can you try this and see if the driver then works? I've already got the kernel debugger on. Do you mean changing the module compile somehow so that more symbols are included? (It seems to resolve the function addresses in the module fine.) compiling with options DDB and makeoptions DEBUG=-g is what i mean Note, on my 5150, I also have a kernel built with -g. I do not have DDB compiled in, but I have never tried a kernel without -g. I may be susceptible to the same all-ffs problem. Joe When i just did a -g, it still would crash when i tried to load the Ahh. I've had DDB on the whole time, but I've found that I don't get a crash (i.e. the all ff's problem) if I don't have my fxp card plugged in when I load the bcm module. dhclient doesn't cause the system to run out of mbufs, but then again it hangs. If I ifconfig the interface manually things work fine. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bcm4400 driver and Dell 8500
On Wed, Aug 27, 2003 at 18:27:57 +0100, Duncan Barclay wrote:
On 27-Aug-2003 Kenneth D. Merry wrote:
On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote:
Hello James and Ken,
Both of you are having real problems with the bcm driver and both of you
have a Dell 8500.
This is James' dmesg output, which from memory looks very similar to your
Ken?
bcm0: Broadcom 10/100 Base-T Ethernet mem 0xfaffe000-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
Yep, the messages I get are identical when I load it as a module.
I'm running 5.1-current from august 22nd. I can try pulling down the
latest 5.1 tommorow if you think this might help. This is the same result
as when I tried the driver from over a month ago.
We think that the problem is something to do with the PCI configuration of
the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the
memory map is not right.
Before sending this email I was going to obtain a backtrace. I recompiled
with the symbol table and kernel debugger and now the driver appears to
work fine. Should it work this way?
Hmm interesting. Ken can you try this and see if the driver then works?
I've already got the kernel debugger on. Do you mean changing the module
compile somehow so that more symbols are included? (It seems to resolve
the function addresses in the module fine.)
The stack trace from the module load is:
panic()
bcm_chip_get_core()
bcm_chip_reset()
bcm_attach()
device_probe_and_attach()
etc.
If I boot a kernel with the bcm driver compiled in, and don't attach to the
docking station, it comes up fine until I insert my fxp card in the carbus
slot. Then I get the panic in bcm_ring_rx_eof() that I reported last
night. FWIW, when I have the driver compiled in, the memory location is
identical to location used when the module loads (above), but the ethernet
address is properly decoded:
This is still smelling of memory stuff outside of my experience.
bcm0: Broadcom 10/100 Base-T Ethernet mem 0xfaffe000-0xfaff irq 11 at
device 0.0 on pci2
bcm0: Ethernet address: 00:0b:db:94:bf:42
miibus0: MII bus on bcm0
If I boot a kernel with the bcm driver compiled in, and don't attach to the
docking station, and don't insert my fxp card, I get slightly further. I
tried running dhclient, and got:
All mbufs or mbuf clusters exhausted, please see tuning(7).
bcm0: initialization failed: no memory for rx buffers
Just checked dhclient and it works fine for me.
I just had another failure case (when I loaded bcm(4) as a module but
didn't have my fxp card inserted) where dhclient just hung up. I didn't
get any out of mbufs errors.
Then I tried just manually ifconfiging the interface, and it works!
Here's what netstat -m says:
{erebor:/usr/home/ken:1:0} netstat -nm
mbuf usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 576/608 (in use/in pool)
Total: 576/608 (in use/in pool)
Mbuf cache high watermark: 512
Maximum possible: 34304
Allocated mbuf types:
576 mbufs allocated to data
1% of mbuf map consumed
mbuf cluster usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 575/584 (in use/in pool)
Total: 575/584 (in use/in pool)
Cluster cache high watermark: 128
Maximum possible: 17152
3% of cluster map consumed
1320 KBytes of wired memory reserved (98% in use)
1 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Performance, once I manually assigned an address seems okay; I was able to
ftp a file over from another machine at a little over 11MB/sec.
Cool, thats about right.
If I insert the fxp card after the bcm driver is configured, the cardbus
initialization fails, and then I get the following messages over and over
again:
eek j=6, macCurrent 511, con288
This is a little loop that waits for the card to finish DMAing a packet. There
should be a DELAY(1) in there. But it may be commented out.
That's bad...in general the chip should DMA the packet and then update the
consumer index and generate an interrupt. I don't know how this particular
chip works, though. The DELAY is commented out.
Do we think that cardbus is trashing the memory space somehow?
That could very well be the case. I don't know anything about cardbus,
though.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: BCM4401 ethernet driver
On Tue, Aug 26, 2003 at 20:31:22 +0100, Duncan Barclay wrote:
On 26-Aug-2003 [EMAIL PROTECTED] wrote:
Greetings;
Wondering whatever further may have come of this discussion regarding
FreeBSD support of the built-in ethernet for the Dell Inspiron 8500 Notebook.
Running a dual-boot system with MS Windows XP and FreeBSD 4.8 Release since
5.1
wouldn't seem to install, but not even sure how to make use of drivers beyond
including their device code in the kernel configuration file, which may just
be an issue with this current release.
I fixed the RX problem yesterday. Take a look at
http://people.freebsd.org/~dmlb/
and grab the lastest bcm_...tar.gz file. Untar this into /sys
then
cd /sys/modules/bcm
make
make install
kldload if_bcm
This driver is for -current only.
Once I've done a bit more work on it and committed it, I'll back port to
-stable.
I'm still having the bcm0: strange type for core 0x panic when I
load it as a module.
When I compile it into the kernel, I get a panic on boot. The stack trace
is:
bcm_ring_rx_eof()
bcm_intr()
ithread_loop()
fork_exit()
fork_trampoline()
The specific place in bcm_ring_rx_eof() it is bailing out is:
(kgdb) list *(bcm_ring_rx_eof+0x62)
0xc019e402 is in bcm_ring_rx_eof (../../../dev/bcm/if_bcm.c:958).
953 struct mbuf *m;
954 struct bcm_rxh *rxh;
955 int j = 0, len, flags;
956
957 m = scp-desc_rx_bis[con].mbuf;
958 rxh = mtod(m, struct bcm_rxh *);
959 do {
960 /* XXX DELAY(1); */
961 bus_dmamap_sync(scp-tag_mbuf,
962 scp-desc_rx_bis[con].dmamap,
i.e. the mtod() call there.
At that point the interface hasn't been configured at all...
I've got a Dell 8500 laptop.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom NetXtreme BCM5705M support
On Sun, Jul 13, 2003 at 16:59:56 +0300, Boris Georgiev wrote: Hello All, I've got a Compaq Evo N620c notebook, which comes with a built-in lan network card - Broadcom NetXtreme BCM5705M. I researched on the hardware support for this NIC in FreeBSD and noticed that there is no hardware support for it either in the STABLE, or in the CURRENT distribution. I found that there is Linux driver for this NIC, which can be downloaded from the 3Com web site on the following address: http://support.3com.com/infodeli/tools/nic/linux/bcm5700-5.0.5.tar.gz The driver comes as a RedHat binary, Linux kernel patch and standalone source. Can you, please update me if there is an updated if_bge driver, which includes hardware support for this new chip or if someone is porting this driver for FreeBSD and there is a beta version, I can cooperate with testing it. Please wrap your lines at something less than 80 columns. Bill Paul just posted a message to -current, -net and -mobile about some patches to the bge(4) driver to hopefully support that chip: http://www.freebsd.org/~wpaul/Broadcom/5705 Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with a firewire external hard disk [long]
On Wed, Dec 04, 2002 at 23:19:56 +0100, Thierry Herbelot wrote: Hello, I can't seem to use my new external firewire hard disk : (this is with 5.0-DP2, there are the same kinds of symptoms under 4.7-Stable) My main question is to know where the problems are : is the hard disk dead ? is the firewire/ATA bridge fried ? are all problems due to the driver ? Any help very much appreciated (or hints to get debugging / trace info) TfH Here follows a list of problems encountered : 1/ error messages at startup when booting, the disk is detected as : (for 5.0-DP2) firewire0:Discover new S400 device ID:00a0b80037aa bus_explore done Device SBP-II sbp_post_explore: EUI:00a0b80037aa spec=1 key=1. sbp0:0:0 LOGIN sbp0:0:0 ordered:0 type:0 EUI:00a0b80037aa node:0 speed:2 maxrec:5 new! sbp0:0:0 'LSI Logic' 'SYM13FW500-DISK DRIVE' 'a0b835' sbp0:0:0 login: len 16, ID 0, cmd f001, recon_hold 1 sbp0:0:0 sbp_busy_timeout sbp0:0:0 sbp_agent_reset sbp0:0:0 sbp_do_attach sbp0:0:0 sbp_cam_scan_lun sbp0:0:0 ORB status src:1 resp:0 dead:1 len:3 stat:c orb:0008c83a4 sbp0:0:0 Request aborted sbp0:0:0 sbp_agent_reset sbp0:0:0 XPT_SCSI_IO: cmd: 12 01 80 00 ff 00 00 00 00 00, flags: 0x40, 6b cmd/255b data/18b sense sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 5 code 24 qlfr 0 len 3 It's complaining there about the serial number inquiry. That's normal, and you'll notice there are no CAM errors showing up from it. The firewire code is just being chatty. sbp0:0:0 ORB status src:1 resp:0 dead:1 len:3 stat:c orb:0008c84d8 sbp0:0:0 Request aborted sbp0:0:0 sbp_agent_reset sbp0:0:0 XPT_SCSI_IO: cmd: 00 00 00 00 00 00 00 00 00 00, flags: 0xc0, 6b cmd/0b data/32b sense sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 6 code 29 qlfr 0 len 3 Now it's reporting unit attention, which is normal after power on. Again, we retry the command so it isn't a problem. sbp0:0:0 ORB status src:1 resp:0 dead:1 len:3 stat:c orb:0008c89a8 sbp0:0:0 Request aborted sbp0:0:0 sbp_agent_reset sbp0:0:0 XPT_SCSI_IO: cmd: 12 01 80 00 ff 00 00 00 00 00, flags: 0x40, 6b cmd/255b data/18b sense sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 5 code 24 qlfr 0 len 3 It's complaining about the serial number inquiry again, doesn't like it. That's not a problem. da0 at sbp0 bus 0 target 0 lun 0 da0: LSI Logi SYM13FW500-DISK b835 Fixed Simplified Direct Access SCSI-0 device da0: 50.000MB/s transfers da0: 28615MB (58605120 512 byte sectors: 255H 63S/T 3648C) I'm a bit disturbed by the Request aborted messages 2/ Geometry problems furthermore, I can't use more than the first 1024 cylinders of the disk : I cannot create a BIOS partition above cylinder 1024 (all partitions seem cut at 1024, when seen from the 4.7-Stable of 5.0 fdisk, even when forcing 3648 cylinders for the size) [ someone else will have to address the fdisk issues ] 3/ Write errors when I try to write to any partitions, one write operations ends as stuck, with an error message such as : Dec 4 21:41:09 portable-cur kernel: sbp_scsi_status: unknown scsi status Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 sbp_abort_ocb 0x1b Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 XPT_SCSI_IO: cmd: 2a 00 00 00 00 9f 00 00 20 00, flags: 0x80, 10b cmd/16384b data/32b sense Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 ORB status src:0 resp:1 dead:1 len:3 stat:4 orb:0008c8fac Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 Object: Operation request block (ORB), Serial Bus Error: Busy retry limit exceeded(X) Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 unordered execution order:1 Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 sbp_agent_reset Looks like some sort of firewire error (i.e. not a SCSI error coming back from the drive). Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 XPT_SCSI_IO: cmd: 2a 00 00 00 00 9f 00 00 20 00, flags: 0x80, 10b cmd/16384b data/32b sense Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 SCSI status 8 sfmt 0 valid 0 key b code 8 qlfr 0 len 3 Dec 4 21:41:09 portable-cur kernel: sbp_scsi_status: unknown scsi status Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 sbp_abort_ocb 0x1b Now the drive says it's busy. Note that no CAM error has been printed for this one -- it probably got retried. Dec 4 21:41:09 portable-cur kernel: sbp0:0:0 XPT_SCSI_IO: cmd: 2a 00 00 00 00 7f 00 00 20 00, flags: 0x80, 10b cmd/16384b data/32b sense Dec 4 21:41:10 portable-cur kernel: sbp0:0:0 ORB status src:0 resp:1 dead:1 len:3 stat:4 orb:0008c9214 Dec 4 21:41:10 portable-cur kernel: sbp0:0:0 Object: Operation request block (ORB), Serial Bus Error: Busy retry limit exceeded(X) Dec 4 21:41:10 portable-cur kernel: sbp0:0:0 unordered execution order:1 Dec 4 21:41:10 portable-cur kernel: sbp0:0:0 sbp_agent_reset This is a firewire-level
Re: DVD-RAM: multi-session writing
On Mon, Sep 09, 2002 at 13:34:28 -0400, Charles Peterman wrote: FreeBSD 4.5. Hitachi DVD-RAM drive I have to support writing files to a DVD-RAM in a Windows compatible mode. Normally I would treat the thing as a slow HD and read and write at my leisure, but Windows does not play nicely with UFS. So I came upon the solution of writing an ISO image out to the disk, like so: readcd dev=$DVDRAM_SCSI_ID -w f=image.iso. Now this works and is portable, but it has an unfortunate side effect. If I attempt to write another image out, I overwrite the existing data. So, there are three possible solutions: 1. Move to UDF, (works for me, but management is scared of anything labelled a kernel change) FreeBSD's UDF code doesn't have write support yet, I don't think. You'd have to use something like mkisofs to make an image and dump it on the drive. 2. Figure out some way to get the first sector after the last ISO from the disk, and start writing the new data there. (I checked camtools and readcd and came up with nothing.) 3. Make a new ISO with all of the old and the new data, write that out to disk. (A bit resource intense, but it should work.) The question for you is whether I was thorough enough evaluating method 2. Is there some way to find out the last sector used on a SCSI device from the command line? If not, is there some way to roll my own? Check out the -C and -M options for mkisofs. Also, you don't need to use readcd to write the image. You can just use dd. e.g.: dd if=image.iso of=/dev/cd0c bs=2k (you can use seek= to jump forward on the disk, so you don't have to start from the beginning each time) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gigabit NIC of choice?
On Fri, Sep 06, 2002 at 10:32:12 -0700, Terry Lambert wrote: Dan Ellard wrote: What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). You'll get good performance with the Tigon II with jumbo frames under -current with ZERO_COPY_SOCKETS and TI_JUMBO_HDRSPLIT turned on. Note that good performance == lower CPU utilization here, although it is difficult to see any improvement in -current with SMP enabled, and the improvement isn't as large in UP mode as it used to be. You can easily get wire rates with jumbo frames with a Tigon II without zero copy, given a reasonably fast machine. (At least on -stable. Reasonably fast == 1GHz Pentium III, 64 bit PCI.) With 1500 byte frames, though, the Tigon II won't perform as well as some other controllers. For most folks, performance with 1500 byte frames is what matters, since you usually need a jumbo-capable gigabit switch to take advantage of jumbo frames in anything more than a point to point environment. The modifications I made to the Tigon firmware (the ones that are in FreeBSD) are actually relatively minor. The main trick is to make sure that the header is in its own scatter/gather element, so the payload will be page aligned. (Assuming the second and subsequent scatter/gather elements are page aligned.) So if your workload consists of jumbo frames for the most part, and receive performance is important, I would suggest a Tigon II-based board, like the GA620T, if you can find one. (Obviously that's getting more and more difficult nowadays.) Otherwise, I would suggest another card with better performance with 1500 byte frames. (I haven't done any tests with other boards, so I can't make specific recommendations.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ultra320 drivers?
On Fri, Aug 30, 2002 at 12:11:12 -0700, Lars Eggert wrote: Peter Wemm wrote: Lars Eggert wrote: We just got a bunch of Dell machines that have this controller as well. Any news about support in sym? No, you want the 'mpt' driver that Matt Jacob recently committed. The 1030 has nothing in common with sym. I backported the mpt driver from -STABLE to 4.6-RELEASE, and it is recognized correctly: mpt0: LSILogic 1030 Ultra4 Adapter port 0xdc00-0xdcff mem 0xff6a-0xff6b,0xff6c-0xff6d irq 18 at device 12.0 on pci3 mpt1: LSILogic 1030 Ultra4 Adapter port 0xd800-0xd8ff mem 0xff66-0xff67,0xff68-0xff69 irq 19 at device 12.1 on pci3 However, my drives aren't attached as Ultra-320 but at much lower speeds: da0 at mpt1 bus 0 target 0 lun 0 da0: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da0: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at mpt1 bus 0 target 1 lun 0 da1: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da1: 62.500MB/s transfers (31.250MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) When I hook them up to the Ultra-160 onboard Adaptec chip, things look better: ahc0: Adaptec aic7892 Ultra160 SCSI adapter port 0xd400-0xd4ff mem 0xff6fe000-0xff6fefff irq 14 at device 14.0 on pci3 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ... da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) Any ideas on how to make mpt use Ultra-320 to talk to the drives? Did you also backport rev 1.35 and 1.36 of scsi_all.c? You may need that as well. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ultra320 drivers?
On Fri, Aug 30, 2002 at 12:50:14 -0700, Lars Eggert wrote: Kenneth D. Merry wrote: Did you also backport rev 1.35 and 1.36 of scsi_all.c? You may need that as well. Good catch, I missed that file. After applying that patch, they now seem to be detected correctly: da0 at mpt1 bus 0 target 0 lun 0 da0: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) da1 at mpt1 bus 0 target 1 lun 0 da1: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) The bad news is that any kind of extended disk activity (e.g. kernel building), results in a ton of unhealthy messages like this: mpt1: time out on request index = 0xe4 sequence = 0x0cad mpt1: Status 0001; Mask 0001; Doorbell 2400 request state On Chip SCSI IO Request @ 0xff807f34 Chain Offset 0x00 MsgFlags 0x00 MsgContext0x00e4 Bus:0 TargetID1 SenseBufferLength 32 LUN: 0x0 Control 0x0100 WRITE SIMPLEQ DataLength0x4000 SenseBufAddr 0x0005d9e0 CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 HOST_TO_IOC SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt1: mpt_done: corrupted ccb, index = 0xe4 seq = 0x0cad request state Timeout mpt_request: SCSI IO Request @ 0xff807e88 Chain Offset 0x00 MsgFlags 0x00 MsgContext0x00e4 Bus:0 TargetID1 SenseBufferLength 32 LUN: 0x0 Control 0x0100 WRITE SIMPLEQ DataLength0x4000 SenseBufAddr 0x0005d9e0 CDB[0:10] 2a 00 01 3f e1 9f 00 00 20 00 SE32 0xdc3c2830: Addr=0xd0f3000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xdc3c2838: Addr=0xd034000 FlagsLength=0x14002000 HOST_TO_IOC SE32 0xdc3c2840: Addr=0xd136000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt_done: context reply: 0x00e4 Did I miss any more pieces? Nothing under sys/cam seemed recent enough. I don't think there are any other missing pieces. Does this work under a stock version of -stable? That could help you figure out whether this is a problem with your backport. Make sure you get an up-to-date -stable, including version 1.14.2.8 of scsi_all.c. You might also want to talk to Matt Jacob [EMAIL PROTECTED] and see if he can help you out. (dunno if he reads -hackers, thus the reason you might want to send mail directly) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CAM wiring, LUNs and duplicate wired entries
On Tue, Aug 20, 2002 at 00:05:33 -0700, Peter Wemm wrote:
Kenneth D. Merry wrote:
On Mon, Aug 19, 2002 at 13:52:33 -0700, Terry Lambert wrote:
Kenneth D. Merry wrote:
I don't think that's the problem. I think the problem is that the device
at target 8 is getting identified to camperiphnextunit() as a wired devic
e,
when it isn't.
Try the attached patch and see if it fixes things for you.
I haven't tried compiling or running this, so beware.
That's some sneaky code. 8-). If this works and you commit it,
can you add an expository comment?
Maybe. Peter Wemm wrote the hardwiring code, and would likely be in a
slightly better position to explain it.
Actually, Justin implemented the original design, I just changed the
underlying mechanism that it uses. It still uses Justin's algorithms but
looks in different places for the source data. I sort-of understand it,
but it has been a while since I looked at it. :-)
Regarding the patch, yes, it does look like the 'hit = 0' should go inside
the loop. I would have done it more explicitly though, eg:
+++ cam_periph.c2002/08/20 06:48:50
@@ -332,3 +332,2 @@
unit = 0;
- hit = 0;
@@ -338,2 +337,3 @@
while ((i = resource_locate(i, periph_name)) != -1) {
+ hit = 0;
dname = resource_query_name(i);
The same problem is on -current too. It is probably worth changing hit
to wired since that is what it means.
I think this bug came from an earlier verson of the changes where this was
a multi-layered loop, and the resetting of 'hit' got moved too far out when
it collapsed to a single loop.
Justin had the above fix in his local tree, but after discussing it we
figured out that it wouldn't work in all cases.
The reason is, if you hit a partial match at the end of the resource list,
hit will still be set to something non-zero, since you won't be going back
through the loop again to reset hit.
Thus the reason for the for() loop -- it resets hit after each loop
iteration. So hit is always 0 when camperiphnextunit() is invoked, unless
you break out of the loop due to a match.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: CAM wiring, LUNs and duplicate wired entries
On Tue, Aug 20, 2002 at 08:30:29 -0400, Gardner Buchanan wrote: Hi Ken, -Original Message- From: Kenneth D. Merry [mailto:[EMAIL PROTECTED]] Sent: August 19, 2002 16:27 Subject: Re: CAM wiring, LUNs and duplicate wired entries Try the attached patch and see if it fixes things for you. Thanks for this patch. I've built a new kernel with this in place and all seems well; no Duplicate message and everything seems to be in the order I expected. Thanks for the feedback, I'll get it committed. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CAM wiring, LUNs and duplicate wired entries
On Mon, Aug 19, 2002 at 13:45:52 -0400, Gardner Buchanan wrote:
Recently I've noticed that the SCSI ID wiring logic is missidentifying
duplicate IDs with seperate LUNs as duplicates: my kernel config says
this:
# Wired down SCSI unit numbers.
#
devicescbus0 at sym0
deviceda0 at scbus0 target 3 unit 0
devicecd0 at scbus0 target 3 unit 1
deviceda1 at scbus0 target 6
deviceda2 at scbus0 target 9
Here cd0 and da0 have the same bus and target, but are different LUNs. The
probe messages look like this:
Aug 18 17:26:38 akbar /kernel: FreeBSD 4.6-STABLE #7: Sat Aug 17 19:19:11
EDT 2002
...
Aug 18 17:26:39 akbar /kernel: Waiting 3 seconds for SCSI devices to settle
Aug 18 17:26:39 akbar /kernel: (noperiph:sym0:0:-1:-1): SCSI BUS reset
delivered
Aug 18 17:26:39 akbar /kernel: (da0:sym0:0:3:0): Duplicate Wired Device
entry!
Aug 18 17:26:39 akbar /kernel: (da0:sym0:0:3:0): Second device (da device at
scbus0 target 8 lun 0) will not be wired
Aug 18 17:26:39 akbar /kernel: da3 at sym0 bus 0 target 8 lun 0
Aug 18 17:26:39 akbar /kernel: da3: Quantum XP32150W 81HB Fixed Direct
Access SCSI-2 device
Aug 18 17:26:39 akbar /kernel: da3: 20.000MB/s transfers (10.000MHz, offset
15, 16bit), Tagged Queueing Enabled
Aug 18 17:26:39 akbar /kernel: da3: 2050MB (4199760 512 byte sectors: 255H
63S/T 261C)
[ ... ]
Aug 18 17:26:40 akbar /kernel: da0 at sym0 bus 0 target 3 lun 0
Aug 18 17:26:40 akbar /kernel: da0: MATSHITA PD-1 LF-1000 A109 Removable
Optical SCSI-2 device
Aug 18 17:26:40 akbar /kernel: da0: 5.000MB/s transfers (5.000MHz, offset 8)
Aug 18 17:26:40 akbar /kernel: da0: Attempt to query device size failed: NOT
READY, Medium not present
As near as I can make out, the code in cam_periph.c doesn't take into
account LUN when testing for duplicates. I seem to be getting the correct
wired value though. My understanding is I should get cd1, rather than cd0,
if the wired cd0 doesn't probe properly.
I don't think that's the problem. I think the problem is that the device
at target 8 is getting identified to camperiphnextunit() as a wired device,
when it isn't.
Try the attached patch and see if it fixes things for you.
I haven't tried compiling or running this, so beware.
Am I missing the boat on how wiring is meant to work?
I don't think so. It may be that you should use 'lun 0' instead of 'unit
0', but that isn't the source of your problem in this case. (The code
looks for 'lun', not 'unit', but I don't know whether 'unit' is aliased to
'lun' somewhere or other.)
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
//depot/FreeBSD-ken-RELENG_4/src/sys/cam/cam_periph.c#1 -
/usr/home/ken/perforce/FreeBSD-ken-RELENG_4/src/sys/cam/cam_periph.c
*** /tmp/tmp.576.0 Mon Aug 19 14:23:24 2002
--- /usr/home/ken/perforce/FreeBSD-ken-RELENG_4/src/sys/cam/cam_periph.cMon
Aug 19 14:23:12 2002
***
*** 335,341
periph_name = p_drv-driver_name;
snprintf(pathbuf, sizeof(pathbuf), scbus%d, pathid);
i = -1;
! while ((i = resource_locate(i, periph_name)) != -1) {
dname = resource_query_name(i);
dunit = resource_query_unit(i);
if (resource_string_value(dname, dunit, at, strval) == 0) {
--- 335,341
periph_name = p_drv-driver_name;
snprintf(pathbuf, sizeof(pathbuf), scbus%d, pathid);
i = -1;
! for (hit = 0; (i = resource_locate(i, periph_name)) != -1; hit = 0) {
dname = resource_query_name(i);
dunit = resource_query_unit(i);
if (resource_string_value(dname, dunit, at, strval) == 0) {
Re: CAM wiring, LUNs and duplicate wired entries
On Mon, Aug 19, 2002 at 13:52:33 -0700, Terry Lambert wrote: Kenneth D. Merry wrote: I don't think that's the problem. I think the problem is that the device at target 8 is getting identified to camperiphnextunit() as a wired device, when it isn't. Try the attached patch and see if it fixes things for you. I haven't tried compiling or running this, so beware. That's some sneaky code. 8-). If this works and you commit it, can you add an expository comment? Maybe. Peter Wemm wrote the hardwiring code, and would likely be in a slightly better position to explain it. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SCSI device emulation using SCSI host controller
On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: Hi! I beg you all pardon for a question not related directly to FreeBSD, but if the answer is ``yes'', then I believe FreeBSD will be in deal. The question is: Can I emulate a SCSI device (tape, if that matters) using usual SCSI host controller and specific software, or I will definitely need specific hardware? You'll need either the right Adaptec or QLogic controller, but yes, it can be done with FreeBSD. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SCSI device emulation using SCSI host controller
On Tue, Aug 13, 2002 at 21:12:59 -0400, Sergey Babkin wrote: Kenneth D. Merry wrote: On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: Hi! I beg you all pardon for a question not related directly to FreeBSD, but if the answer is ``yes'', then I believe FreeBSD will be in deal. The question is: Can I emulate a SCSI device (tape, if that matters) using usual SCSI host controller and specific software, or I will definitely need specific hardware? You'll need either the right Adaptec or QLogic controller, but yes, it can be done with FreeBSD. Or Symbios (now LSI Logic). Has anyone done any target mode code for their boards? I know they're probably capable of it, but AFAIK, the sym(4) driver doesn't support target mode and I didn't see anything in the mpt(4) commit that indicated that it supports target mode either. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hackers] Multi CDR burn
On Tue, Jul 09, 2002 at 16:22:56 -0400, David Gilbert wrote: Keith == Keith Pitcher [EMAIL PROTECTED] writes: Keith Given the hardware, is there a way to burn 8 CDs at one time, Keith or is there some mirroring code that is well written enough to Keith facilitate it? I wouldn't expect mirroring code to be of help here since FreeBSD's vinum and ccd expect disk formats (not iso_9660) and also expect regular read/write disks, not CDR (which require special treatment anyways). I also didn't know that there was a write-to-many SCSI command? Someone can confirm or deny this? There is no such thing. A narrow SCSI2 bus is 20Mhz * 8 bit or 20 Megabytes per second. A 1x CDROM is 20 kilobytes per second (roughly, I looked it up and several sources said 150 kilobits per second) ... so your single scsi bus should handle 1000 1x CDROMS or 8 125x CDROMS. Simply put, your SCSI channel (even it it's only 10Mhz is way more then enough). Next, let the OS do the work. You'll likely find that you can set the buffers to almost zero (I think the default is one meg). The code will be shared, the data will only be read once and you just might find that it works. UNIX is there to make these simple things work for you. I'll go out on a limb and speculate that there isn't a write-to-many command as you suggest. My understanding of SCSI is that each command addresses one target... and that part of the format is hard-coded. You're correct. With SCSI, one initiator talks to one target, so you can't talk to multiple targets at one time. As long as the drives support disconnection, you should be able to burn multiple CDs at once over one bus. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hackers] Multi CDR burn
On Tue, Jul 09, 2002 at 18:27:16 -0400, Keith Pitcher wrote: I also didn't know that there was a write-to-many SCSI command? Someone can confirm or deny this Coulda sworn the raid controller on our main freebsd machine does mirroring via scsi with a single command. So I took it that this was a scsi card ability and not a raid controller option. You send a single command to the RAID controller, but it will send a command to each disk in the mirror on a write. I did a real quick search of the scsi spec and came across the Single Initiator - Multiple Targets ability but this may not mean what I take it to mean. It doesn't mean you can talk to multiple targets simultaneously. Just that with one SCSI initiator, you can talk to multiple targets one at a time. With SAS (Serial Attached SCSI) that may change, since SAS is inherently a point to point protocol. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How noisy should ch(4) be ?
On Sat, Jun 29, 2002 at 16:17:22 +, Dirk-Willem van Gulik wrote: - run 'chio ielem' before you do anything. This may make the changer look at what it has, and perhaps figure out that it doesn't really have a source addresses for various elements. What about this option? - try moving every tape in the changer to some destination and back. The fastest thing to do, if the changer supports it, would probably be moving the tapes to the picker and then back to a slot. Did not work :-) - comment out the warning in copy_element_status(). Fixed the problem perfectly :-) - see if there is updated firmware for the changer. There is - but it seems to need special third party SCSI software which only works on windows. I've got no desire to disconnect the unit for now. Hmm. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How noisy should ch(4) be ?
On Thu, Jul 04, 2002 at 00:18:11 +0200, [EMAIL PROTECTED] wrote: - run 'chio ielem' before you do anything. This may make the changer look at what it has, and perhaps figure out that it doesn't really have a source addresses for various elements. What about this option? It happily ran the option - but any subsequent command would still yield the chattyness. Interestingly enough 'mtx' (see sourceforge) does the same thing (plus has a few bugs of its own) - but does not cause the warnings. It probably just doesn't mention the problem. I'll think about it a bit, it may be that we can safely comment out the warning. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Retrieving interface MAC address
On Tue, Jun 18, 2002 at 13:41:02 -0700, Kevin D. Wooten wrote: Robert Watson wrote: I tend to retrieve address information about interfaces using getifaddrs(), which will (among other things) retrieve the link layer addresses of an interface. It might be overkill for your application, however. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Tue, 18 Jun 2002, Kevin D. Wooten wrote: How can I go about retrieving the MAC address for an interface? Since SIOCGHWADDR doesn't seem to be implemented. Can anyone help?? Thanks, Kevin Wooten Thanks getifaddrs() works great, just one more thing is there a simple way to tell the difference between real interfaces and virtual ones? I could obviously exclude the easy ones ( i.e. lo, lp, faith, ... ) by looking at the name, but I am not sure how many different virtual interfaces there are ( or will be ). You could cross-reference the interfaces returned by getifaddrs() with the list of PCI devices from the PCIOCGETCONF ioctl. (see pci(4)) It would only work for PCI NICs, but would be better than nothing. There are probably other ways to do it as well. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: port trunking (was Re: FreeBSD Convention in EU)
On Mon, Apr 22, 2002 at 11:12:10 +0200, Andy Sporner wrote: I have an interest to present either on Clustering or perhaps if the timing is right, a feature I am working on to bundle ethernet adapters as a single virtual adaptor (idea taken from Intel Adapter Teaming). You may want to take a look at: http://people.freebsd.org/~wpaul/FEC/ I haven't tried it, but it implements the Cisco Fast Etherchannel stuff. Anyone know why it hasn't made it into -current? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: naive i386 FreeBSD interrupt question
On Thu, Apr 18, 2002 at 12:27:33 -0700, Matthew Jacob wrote: This was -stable- but it's really a hacker's question. I really am *not* much of an i386 weenie and I'll have to admit that I don't fully understand the interrupt mask scheme and I ran into a troubling problem. I was running some very extensive tests on a dual processor (but not SMP configured) system- I was in the middle of calling busdma_load from the isp driver when I got interrupted and blew up fielding an isp interrupt. Now- this shouldn't have happened. When I entered the isp driver, I'd called splcam- this should have blocked me from being interrupted. However, in calling busdma_load, I'd also called splsoftvm() (this is code copied, blindly, from other drivers). Now- if I was running on a 68020 or a Sparc or an Alpha, I would simply have assumed that the splsoftvm had (*smack*) forcibly lowered PIL. Oops. It was just for this reason that in SunOS all named spl calls were turned into s = splr(pritospl(device_interrupt_priority)); which would only raise (if needed) priority- never lower it. So- when I went to try and deduce what was going on for i386, I become a bit confused because, haha, that's right, all interrupts are separately maskable and have nothing really to do (I *think*- I'm paying the price for not really knowing i386 well enough) with a global processor priority level. So- what's the deal here? Why did a call to splsoftm *apparently* unmask the CAM device blockage such that I got interrupted when I thought I was blocked? A short RTFC is a fine answer- but if somebody could clue me in, that'd be nice. I'm no expert on this, but from sys/i386/isa/ipl_funcs.c, it looks like both splsoftvm() and splcam() are |= masks, so they should be in addition to whatever mask you had before. So it looks like things should work as you expected. So why didn't it work as you expected? I dunno. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB Memorybird quirks
On Wed, Apr 10, 2002 at 21:50:33 +0200, Nick Hibma wrote: The problem is that we emulate ATAPI and UFI command sets through converting SCSI commands. These command sets both do not have 6 byte commands. The solution is to have the umass driver pass a quirk back to the CAM layer dynamically for these devices. Any takers for an implementation that doesn't cause a large memory overhead? The solution that doesn't require memory consuming storing of quirks would be to have the da peripheral driver ask the SIM (umass in this case) for the quirks. The umass driver does not know about the attachment of the da driver to the SCSI device we have created (nor should it), so it is difficult to find a way to push the quirk info up to the driver. I'm all ears to good ideas. Using the transport type might be a good way to do this. The CAM_NEW_TRAN_CODE stuff includes a transport field that would basically tell us what we need to know. We'd need to get the rest of the drivers ported over to that interface, though. A second piece of work would be to convert all the other 6 byte commands it produces to their 10 byte equivalents, in the same way it is done in scsi_da.c: Pass softc-minimum_cmd_size into scsi_mode_sense and scsi_mode_select and make those functions use the 10 byte commands where necessary. Be careful about this; scsi_mode_sense(), scsi_mode_select(), etc., are exported to userland through libcam. If we add parameters to the functions, we probably need to create a new function name with the additional parameter, and have the old function call the new one. The alternative might be to just not have the new function exported to userland. In the typical case, you're only going to have problems with 6 bytes reads and writes. A mode sense is only issued if the device claims to support tagged queueing. (To see if the DQue bit is set in mode page 0xa.) There are other commands that can get sent, though -- inquiry, test unit ready, and start/stop unit are all 6 byte commands, and there are no 10 byte SCSI equivalents. So how do you handle those now? And then the third one would be to have a look at for example scsi_cd.c and friends and make similar changes there. The CD driver already uses 10 byte read and write commands, since the 6 byte read/write commands are not required for CD type devices. It does use a 6 byte mode sense/mode select, but since it rolls its own (can't remember why at the moment), that can be easily modified to look at the transport type and optionally use a 10 byte command. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ServerWorks AGP support?
On Mon, Apr 08, 2002 at 11:13:40 -0700, Frank Mayhar wrote: I recently acquired a Tyan S1867 motherboard, which uses the ServerWorks HE chipset. I have a Radeon 7500 video card and I want to be able to do direct rendering with XFree86 4.2. Unfortunately, the ServerWorks chipset doesn't appear to be supported in modules/agp.ko. So, is anyone working on adding such support? I see that the ServerWorks chipset is (or at least appears to be) supported in the Linux AGP code; if necessary I can extract the necessary information from that code to write a driver for FreeBSD, but it would be nice if someone had already done the work, since my time is more than full enough already. :-) I took a look at it a few weeks ago, since I've also got a couple of Serverworks boards with AGP, but I decided that I had more pressing things to do than get DRI working. :) Anyway, I'd say go for it. :) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel debugger and X11.
On Tue, Mar 19, 2002 at 20:15:29 +, Josef Karthauser wrote: I'm having some intermittant problems on my laptop that I'd like to debug, but as I use X11 most of the time it's difficult to use the kernel debugger when the machine hangs, which is when I'm in X :(. Of course the nicest thing would be to return the screen to text mode automatically when the the kernel debugger is entered, but because X controls the video registers I guess that that's not easy or possible. I suppose that the best way is to have a second FreeBSD box and couple them via RS232, but this isn't always convenient. (I seem to have the most time to work on FreeBSD when I'm travelling). Does anyone have any working practices around this problem? I'm sure that I'm not the only one of us with it. I would recommend just enabling crash dumps; then it doesn't matter if you're in X when the machine panics, and you can get a stack trace and look at things once the machine reboots. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel debugger and X11.
On Tue, Mar 19, 2002 at 21:36:23 +, Josef Karthauser wrote: On Tue, Mar 19, 2002 at 02:34:48PM -0700, Kenneth D. Merry wrote: Does anyone have any working practices around this problem? I'm sure that I'm not the only one of us with it. I would recommend just enabling crash dumps; then it doesn't matter if you're in X when the machine panics, and you can get a stack trace and look at things once the machine reboots. I suppose. Is it possible to switch the debugger off via a sysctl, without compiling it out? From sys/kern/kern_shutdown.c: #ifdef DDB #ifdef DDB_UNATTENDED int debugger_on_panic = 0; #else int debugger_on_panic = 1; #endif SYSCTL_INT(_debug, OID_AUTO, debugger_on_panic, CTLFLAG_RW, debugger_on_panic, 0, Run debugger on kernel panic); #endif So you should be able to turn it off with debug.debugger_on_panic. From a grep through the tree, it looks like only i386 and powerpc look at that variable. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: suspected dying CD-writer ?
On Wed, Jan 23, 2002 at 23:24:16 +0100, Thierry Herbelot wrote: Hello, I've got an SCSI CD-Writer, which only gives errors when I try to use cd-record (see full log at the end of the message) As the problem is identical on a fresh 4.4-Rel (with cd-record installed from the CD as a binary package) and a recently updated 4.5-RC, there is strong suspicion the drive itself is dying. can anyone decode the ASCII dump of the SCSI error message ? (I've also cleaned the optics, in case there was too much dust, but no joy) time to buy a new Yamaha 2100S ? TfH # cdrecord -v dev=0,2,0 speed=1 blank=fast The error below is an illegal/invalid opcode. It doesn't really indicate a failing drive, as far as I can tell. cdrecord: Drive needs to reload the media to return to proper status. ATIP start of lead out: 1166730 (03:18/30) Blocks total: 1166730 Blocks current: 1166730 Blocks remaining: 1166880 Starting to write CD/DVD at speed 1 in write mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Blanking PMA, TOC, pregap cdrecord: Input/output error. blank unit: scsi sendcmd: retryable error CDB: A1 01 00 00 00 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 05 00 00 00 00 28 00 00 04 D8 20 00 00 80 00 00 01 19 04 00 00 00 80 01 00 00 00 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x20 Qual 0x00 (invalid command operation code) Fru 0x0 Sense flags: Blk 0 (valid) error refers to data part, bit ptr 0 (not valid) field ptr 0 cmd finished after 5.618s timeout 9600s cdrecord: Cannot blank disk, aborting. I would suggest either not specifying the speed, or specify a speed that both the media and the drive can handle. Some media have a minimum speed. If that doesn't fix it, send mail describing the problem to [EMAIL PROTECTED], or Joerg Schilling directly -- [EMAIL PROTECTED] Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Sat, Sep 29, 2001 at 21:27:46 -0700, Terry Lambert wrote: Kenneth D. Merry wrote: Unfortunately, it can not correctly interoperate with a number of cards in jumbogram mode, so unless you know the card on the other end and manually configure it (it can't negotiate properly), you can't really use jumbograms. Or you could rewrite the firmware (of course). Huh? Care to explain? Why wouldn't it interoperate with jumbo frames? Why are jumbo frames something that need be negotiated by the card? They're not negotiated by the card, but rather by the TCP stack. Because at the time the Tigon II was released, the jumbogram wire format had not solidified. Therefore cards built during that time used different wire data for the jumbogram framing. Can you give more details? Did someone decide on a different ethertype than 0x8870 or something? That's really the only thing that's different between a standard ethernet frame and a jumbo frame. (other than the size) I have never seen the board with the stock FreeBSD driver get better than about half wire rate with normal size packets and window depth. Yep, it doesn't handle large numbers of small packets very well. You can easily get wire rate with jumbo frames, though. Again, that's not useful, since it requires hand negotiation; you can't automatically set the MTU up as a result of doing a driver level negotiation with the other end of the link (unless the other end is also a Tigon II). Negotiation, at least for packet size, is generally done at a higher level than the transport layer (ethernet in this case). Your routing hardware should be able to send back ICMP need fragment responses if an IP packet has the don't frag bit set, or it should be able to fragment the packet if it doesn't have that bit set. On the other hand, the Tigon III is capable of 960 megabits -- about the wire rate limit -- with normal size packets, if you implement software interrupt coelescing (which doesn't help, unless you crank the load up to close to wire speed and/or do more of the stack processing at interrupt time). The Tigon II also has the unfortunate need to download its firmware, and a FreeBSD bug -- the lack of a distinct state for firmware download -- means that the firmware get sent to the card each time the thing is config'ed up, or an IP alias is added to the thing. Plus the damn things are more expensive than the Tigon III based cards. That's partially because Bill wanted to have a process context when he was downloading the firmware, and didn't want to do a kernel thread to do it. Bill and I discussed this at length, in person. The problem is that FreeBSD resets the ethernet cards, for fear that it is the user's intent to recover a hung card tis way. The firmware download issue is because there is not a seperate entry point for firmware download, combined with the initial gratuitous ARP request being placed on the transmit queue for the card before it is really up, and the only other alternative place to hook the firmware download meant that you would have to hang the ifconfig command -- nad therefore the /etc/rc, and therefore the boot process -- waiting for th download to complete. The upshot of this is that adding a virtual IP address to the interface is assumed to be a very infrequent event. This assumption is incorrect for a large number of IP takeover protocols (e.g. VRRP), whose timing granularity is small enough that the firmware download exceeds the interval by a factor of 10 or more. By the time the alias address assignment (and the concommitant firmware download) are completed, the takeover window has been greatly exceeded. For all three of the takeover protocols for which there is published documentation available, this results in the address being configured on, the firmware downloaded, the takeover window being missed, losing the contention race for the takeover, and the address being configured off -- and the firmware being downloaded yet again. Another amusing consequence is that, if there is traffic at the time of the event, the driver goes into a perpetual watchdog timeout: resetting loop, which can oly be resolved by a system reboot. That certainly sounds like a problem. So it gets done when the card is ifconfiged up. I wrote some code for my former employer to wait up to 10 seconds for link to show up when the board is configured. The alternative is a 'sleep 5' (for fiber boards) or 'sleep 8' (for copper boards) after it is ifconfiged up. The kernel code is trivial, but it's not in there by default, and wouldn't need to be there, if there were a firmware download phase for the card which could be triggered to occur asynchronously (e.g. so that the driver did not hand user space in the attach). True. The sleep workaround doesn't really work, unless you're willing to hack up your rc
Re: TCPIP cksum offload on FreeBSD 4.2
On Sat, Sep 29, 2001 at 12:00:59 -0700, Terry Lambert wrote: Kenneth D. Merry wrote: [ ... transmit checksum offload ... ] You've got things confused. I think that may be a limitation of some SysKonnect boards, but certainly isn't a Tigon limitation. Yes, it's not Tigon chipset specific. It's not a Tigon chipset problem at all. Tigon boards come with 512KB, 1MB, or 2MB (never seen one of these) of SRAM on board. The firmware takes a couple hundred KB, so you generally have at least 200KB, and possibly a good bit more for packet storage space on the card. So there is buffer space for a number of packets on both the send and receive sides, and checksumming works in both directions. This depends on the driver division of memory; fortunately, the FreeBSD driver is OK in this regard. I suppose if you set the transmit/receive buffer ratio all the way to one side or the other, you'd have problems, but any driver writer with half a clue wouldn't do that. Also note that this card is not known to be the fastest one ot there, so you may be better off doing the checksum on your 1GHz+ host processor instead. You can get wire rate with a Tigon 2 board, with jumbo frames at least. (That's with checksum offloading enabled.) Unfortunately, it can not correctly interoperate with a number of cards in jumbogram mode, so unless you know the card on the other end and manually configure it (it can't negotiate properly), you can't really use jumbograms. Or you could rewrite the firmware (of course). Huh? Care to explain? Why wouldn't it interoperate with jumbo frames? Why are jumbo frames something that need be negotiated by the card? They're not negotiated by the card, but rather by the TCP stack. I have never seen the board with the stock FreeBSD driver get better than about half wire rate with normal size packets and window depth. Yep, it doesn't handle large numbers of small packets very well. You can easily get wire rate with jumbo frames, though. On the other hand, the Tigon III is capable of 960 megabits -- about the wire rate limit -- with normal size packets, if you implement software interrupt coelescing (which doesn't help, unless you crank the load up to close to wire speed and/or do more of the stack processing at interrupt time). The Tigon II also has the unfortunate need to download its firmware, and a FreeBSD bug -- the lack of a distinct state for firmware download -- means that the firmware get sent to the card each time the thing is config'ed up, or an IP alias is added to the thing. Plus the damn things are more expensive than the Tigon III based cards. That's partially because Bill wanted to have a process context when he was downloading the firmware, and didn't want to do a kernel thread to do it. So it gets done when the card is ifconfiged up. I wrote some code for my former employer to wait up to 10 seconds for link to show up when the board is configured. The alternative is a 'sleep 5' (for fiber boards) or 'sleep 8' (for copper boards) after it is ifconfiged up. Having downloadable firmware is actually a huge advantage. You can do things with the Tigon II that just aren't possible with any other chip, either because they don't have downloadable firmware, or because the vendor won't release firmware source. This is a problem with the Broadcom Tigon III boards, and to some extent with the Tigon II. Basically it looks like the firmware for the Tigon II is very hard to get now that 3Com has control of it, and I don't think Broadcom will release the Tigon III firmware. (Assuming it is a firmware-based chip.) To put a final nail in the coffin, the card can't offload TCP checksum with VLANs enabled (it breaks). Probably something that could be fixed in the firmware. Too bad the vendor isn't really supporting it very much now. All in all, the Tigon II is a bad board. That's your opinion, but I disagree. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Fri, Sep 28, 2001 at 01:01:20 -0700, Terry Lambert wrote: Jonathan Lemon wrote: I'm trying to use the TCPIP checksum offload capability of the Netgear GA620 NIC from a SMP FreeBSD 4.2R system running on a typical PIII SBC. I did enable TCPIP cksum offload for receive operations by setting the if_hwassist flag in the driver /sys/pci/if_ti.c and verified that it is working. However I'm unable to offload TCPIP checksum for the send operations. All you need to do is uncomment the TI_CSUM_FEATURES flag at the top of the file, and recompile. He didn't say his packet size, either. To the original poster: if you are sending jumbograms, the buffer size on these cards is limited, so the entire packet can't be in the card buffer at the same time, which means that you can not offload the send checksum for jumbograms, only for regular sized packets. You've got things confused. I think that may be a limitation of some SysKonnect boards, but certainly isn't a Tigon limitation. Tigon boards come with 512KB, 1MB, or 2MB (never seen one of these) of SRAM on board. The firmware takes a couple hundred KB, so you generally have at least 200KB, and possibly a good bit more for packet storage space on the card. So there is buffer space for a number of packets on both the send and receive sides, and checksumming works in both directions. Also note that this card is not known to be the fastest one ot there, so you may be better off doing the checksum on your 1GHz+ host processor instead. You can get wire rate with a Tigon 2 board, with jumbo frames at least. (That's with checksum offloading enabled.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 23:42:50 -0700, Mike Smith wrote: On Wed, Jul 04, 2001 at 20:18:51 -0400, Kevin Hui wrote: Then the question is whether the kernel is copying data between userspace and kernelspace or whether it just DMAs the data straight in/out of the user program's address space. In Linux raw-io, given that it is a block device and you are doing page-aligned block I/Os on it, is smart and does zero copies. While it may seem to be jumping through hoops, maybe it does have a performance advantage? The kernel copies between userland and the kernel. Er, no. See sys/kern/kern_physio.c for the details. *hits head* I (of all people) should have remembered that. I wrote the zero copy stuff for the pass(4) driver (see cam_periph_mapmem() in sys/cam/cam_periph.c) using physio as a model. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 17:58:58 -0400, Kevin Hui wrote: Hi all, I'm wondering if *BSD have any support for user programs to access raw disk devices, unbuffered. Such support is available under Linux: http://www.kernel.org/LDP/HOWTO/SCSI-2.4-HOWTO/rawdev.html http://www2.linuxjournal.com/cgi-bin/linux/man.cgi?mode=searchcomm=rawsect=1 Any information regarding this would be appreciated. There are no block (i.e. buffered) devices in FreeBSD, only character devices. So you can access raw devices without having to go through all the hoops described above. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 20:18:51 -0400, Kevin Hui wrote: Then the question is whether the kernel is copying data between userspace and kernelspace or whether it just DMAs the data straight in/out of the user program's address space. In Linux raw-io, given that it is a block device and you are doing page-aligned block I/Os on it, is smart and does zero copies. While it may seem to be jumping through hoops, maybe it does have a performance advantage? The kernel copies between userland and the kernel. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: I am working on a FreeBSD device driver for my Co's GSN adapter and need to be able to set my TCP/IP window size to 512KB (or perhaps more). I have tried doing this with sysctl: root@sebulba:p0 /root sysctl -w net.inet.tcp.recvspace=524288 net.inet.tcp.recvspace: 131072 - 524288 root@sebulba:p0 /root sysctl -w net.inet.tcp.sendspace=524288 net.inet.tcp.sendspace: 131072 - 524288 and although the sysctl happily takes the specification, when I attempt an ftp command I get: root@sebulba:p0 /root ftp 192.168.1.2 ftp: socket: No buffer space available This is on a FreeBSD 4.0-stable system: FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 15:09:46 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 Anybody have any ideas what I need to do to get this to work? sysctl -w net.inet.tcp.rfc1323=1 You need that to be able to set your window size to anything over 64K. I think there's an rc.conf knob to do that so you don't have to tweak it manually every time. You really don't want to use ftp to test bandwidth. Use netperf instead. It is located in ports/benchmarks. You might also be interested in the zero copy patches. See: http://people.FreeBSD.org/~ken/zero_copy/ The latest patches aren't linked off the page, they're available here: http://people.FreeBSD.org/~ken/zero_copy/zero_copy.diffs.20010124 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realy LARGE TCP/IP Window Size?
On Mon, May 07, 2001 at 17:15:20 -0500, Bob Willcox wrote: On Mon, May 07, 2001 at 04:45:31PM -0500, Bob Willcox wrote: On Mon, May 07, 2001 at 03:38:02PM -0600, Kenneth D. Merry wrote: On Mon, May 07, 2001 at 16:20:05 -0500, Bob Willcox wrote: I am working on a FreeBSD device driver for my Co's GSN adapter and need to be able to set my TCP/IP window size to 512KB (or perhaps more). I have tried doing this with sysctl: root@sebulba:p0 /root sysctl -w net.inet.tcp.recvspace=524288 net.inet.tcp.recvspace: 131072 - 524288 root@sebulba:p0 /root sysctl -w net.inet.tcp.sendspace=524288 net.inet.tcp.sendspace: 131072 - 524288 and although the sysctl happily takes the specification, when I attempt an ftp command I get: root@sebulba:p0 /root ftp 192.168.1.2 ftp: socket: No buffer space available This is on a FreeBSD 4.0-stable system: FreeBSD sebulba.vieo.com 4.0-STABLE FreeBSD 4.0-STABLE #202: Mon May 7 15:09:46 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GPXTEST i386 Anybody have any ideas what I need to do to get this to work? sysctl -w net.inet.tcp.rfc1323=1 You need that to be able to set your window size to anything over 64K. I think there's an rc.conf knob to do that so you don't have to tweak it manually every time. Thanks, I'll give this a try. I tried setting the above sysctl but that didn't have any effect on the problem. Through a binary search of send and recv space settings I was able to determine that anything over 227 KB (232448 bytes) fails when I attempt to open a TCP socket. You probably also need: sysctl -w kern.ipc.maxsockbuf=2097152 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Acenic driver questions
On Wed, Apr 04, 2001 at 09:48:24 -0400, Amy Fong wrote: Question about the acenic driver. In if_ti.c, there's ti_mem which is currently used to load the firmware onto the card. What I'm trying to do is to use take advantage of the window base/window from the registers on the tigon and write to a particular segment of the memory. From what I've seen so far, it looks like I should be able to do this using ti_mem to do this but my experimentations don't seem to be working. I know that Linux acenic driver has patches available for using the window/winbase to read the nic's tracing ring buffer so I'm thinking that I should be on the right track. Does anyone have any experience/suggestions? Look at the Tigon driver diffs in this patch set: http://people.FreeBSD.org/~ken/zero_copy/zero_copy.diffs.20010124 In particular, look at the ti_copy_mem() function. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Acenic driver questions
On Wed, Apr 04, 2001 at 11:22:25 -0400, Amy Fong wrote: Thanks! I should be kicking myself right now. I looked at the zero copy code a few months back and totally forgot about it. While I'm wasting bandwidth, I've got another question. I've noticed that if I use up too much stack space, the freebsd kernel (4.2) seems to crash very easily. Specially, if I create an array of size N within a function, once the function gets invoked, my machine just reboots. How do I find out how much stack space I've got? I'm assuming that it _is_ a stack issue. :) Other folks will probably have a better answer, but... if you're running into trouble like that, you should probably be mallocing the array in question. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Best Gigabit ethernet for 4.x
On Sat, Mar 24, 2001 at 12:31:05 -0500, Dennis wrote: At 05:04 PM 11/18/2000, Kenneth D. Merry wrote: On Sat, Nov 18, 2000 at 11:33:29 -0500, Dennis wrote: At 04:28 PM 11/17/2000, Schmalzbauer, Harald wrote: I just heard that Intel doesn't supply documentation on ther chipset and the FreeBSD and Linux support is quiet bad. The Netgear GA620 is said to be twice as fast. The same Chipset (Alteon Tigon/AceNIC) is on the 3com985. Are all of the cards supported that use this chipset? I read somewhere that the netgear card has a smallish buffer, and that the alteon was a better choice. How does the 3com card compare in that respect? The Netgear boards have 512K SRAM, the 3Com boards have 1MB SRAM. You can get Alteon-branded boards (with either 512K or 1MB SRAM), but generally only directly from Alteon, and you're going to pay more than you would for either the 3Com or Netgear boards. The 3Com and Netgear boards are identical to the Alteon boards. The only difference is they've got "Netgear" or "3Com" silk-screened on them, and the Alteon boards don't have any logos on them. FWIW, 3Com is buying Alteon's NIC group. Apparantly (according to an Alteon engineer who posted on the linux-acenic list) they're just buying the technology, not hiring the engineers: When you say "identical", that implies that they are the same...or do you just mean that they use the same parts? It seems unlikely that alteon would allow netgear to license its product and them sell it for 1/2 the price. Alteon evidently didn't want to undersell their OEMs. I think most of their NIC business was via sales from Netgear, 3Com, etc., and not via direct sales of their own NICs. (Which you could only buy direct from Alteon.) And the cards are pretty much the same, except that the Alteon boards generally have no identifying markings on them, whereas the Netgear and (I think) 3Com boards have the vendor's name silk-screened on the board. Price is not an issue at this level as performance is tantamount, but Im not sure you'd need more than 512M with unix unless you have several NICs in a box. I'd like to see a Gigabit board with 512M. :) Assuming you mean 512K, you're probably right, that would be sufficient in many situations. The thing to remember is that you don't get the entire 512K for caching packets, since part of it (less than half) is used for the firmware and data structures. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
On Tue, Mar 06, 2001 at 10:56:46 -0500, Andrew Gallatin wrote:
Matt Dillon writes:
I modified my original C program again, this time to simply read
the data from memory given a block size in kilobytes as an argument.
I had to throw in a little __asm to do it right, but here are my results.
It shows about 3.2 GBytes/sec from the L2 (well, insofar as my
3-instruction loop goes), and about 1.4 GBytes/sec from main memory.
NOTE: cc x.c -O2 -o x
./x 4
3124.96 MBytes/sec (read)
...
./x 1024
1397.90 MBytes/sec (read)
In contrast I get 1052.50 MBytes/sec on the Dell 2400 from the L2,
and 444 MBytes/sec from main memory.
FWIW: 1.2GHz Athlon, VIA Apollo KT133 chipset, Asus A7V motherboard,
(PC133 ECC Registered Dimms)
./x 4
2393.70 MBytes/sec (read)
./x 8
2398.19 MBytes/sec (read)
...
./x 1024
627.32 MBytes/sec (read)
And a Dual 933MHz PIII SuperMicro 370DER Serverworks HE-SL Chipset
(2-way interleaved PC133 ECC Registered DIMMS)
./x 4
1853.54 MBytes/sec (read)
./x 1024
526.19 MBytes/sec (read)
Dell Precision 420 (i840 chipset) with a single PIII 800 and probably one
RIMM, unknown speed:
{rivendell:/usr/home/ken/src:76:0} ./memspeed 4
1049.51 MBytes/sec (read)
{rivendell:/usr/home/ken/src:77:0} ./memspeed 1024
378.41 MBytes/sec (read)
The above machine may not have been completely idle, it seems a little
slow.
Dual 1GHz PIII SuperMicro 370DE6 Serverworks HE-SL chipset, 4x256MB PC133
ECC Registered DIMMs:
{gondolin:/usr/home/ken/src:51:0} ./memspeed 4
1985.95 MBytes/sec (read)
{gondolin:/usr/home/ken/src:52:0} ./memspeed 1024
516.62 MBytes/sec (read)
There's something diabolic about your previous bw test, though. I
think it only hits one bank of interleaved ram. On the 370DER it gets
only 167MB/sec. Every other bw test I've run on the box shows copy
perf at around 260MB/sec (Hbench, lmbench). I see the same problem on
a PE4400 (also 2-way interleaved); it shows copy perf as 111MB/sec.
Every other test has it at 230MB/sec.
The previous test showed about 270MB/sec on my Serverworks box:
{gondolin:/usr/home/ken/src:53:0} ./memory_speed
269.23 MBytes/sec (copy)
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI DAT tape detection on Compaq DL380
On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: Dear all, I have a Compaq DL380 with an integrated Compaq Smart Array Controller. I have succesfully managed to install the FreeBSD 4.2-20010104 and everything is fine but the DAT drive which is not detected. The DAT is connected to the same Controller as the RAID system. I have checked the archives and noticed that I am not the first one who has this problem. But I could not find any resource which could lead me to a solution. If any of you could give me any hints on that, I would be very grateful. I am at the point where I am considering switching to Linux because of that. I don't think the ida driver in FreeBSD has SCSI passthrough capability. That is to say that it doesn't hook into the CAM subsystem so that generic tape, CDROM, changer, etc., devices will work. I don't know whether or not the hardware itself has passthrough capability; someone more familiar with those controllers will have to comment on that. If the hardware can't handle it, switching to Linux won't help you. If it does handle it, switching will only help if the Linux driver supports that functionality. On the other hand does any of you have info whether Compaq will support officially FreeBSD in the future? I don't know. They offer FreeBSD in their test drive program, though: http://www.testdrive.compaq.com Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Sat, Dec 02, 2000 at 21:38:19 -0700, Lyndon Nerenberg wrote: "Kenneth" == Kenneth D Merry [EMAIL PROTECTED] writes: Is there any reason why the FWRITE test cannot/should not be moved down into the 'case PCIOCWRITE' part of the switch? This would make both PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which seems to me to be saner behaviour). Kenneth At least with the PCIOCGETCONF, you need write Kenneth permission, because it copies in patterns to match Kenneth against. Does that have to equate with write access? Since you aren't changing anything (device-wise) it seems this should be a read-only thing (even though you're actually writing into the kernel memory arena). From your comments below, you apparantly don't have to have write access to do a copyin. I would like to have pciconf -l available for normal users, but my only hesitation is that there could be security implications. If we can get someone (i.e. a security type person) to check the PCIOCGETCONF code carefully for any potential problems, then we can enable it for normal users. The code wasn't written with security in mind, so I don't want to open it up to regular users without a security evaluation. If we can get that, then I don't see a problem with allowing read only access for that ioctl. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 01, 2000 at 13:56:13 -0700, Lyndon Nerenberg wrote: [Observed on 4.2-STABLE, but I've redirected replies to the hackers list.] 'pciconf -l' is documented to work for non-priv users, however the first thing the underlying ioctl code (pci_ioctl) does is bail with EPERM if the caller does not have /dev/pci open for write. The documentation is wrong, unfortunately. Is there any reason why the FWRITE test cannot/should not be moved down into the 'case PCIOCWRITE' part of the switch? This would make both PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which seems to me to be saner behaviour). At least with the PCIOCGETCONF, you need write permission, because it copies in patterns to match against. As for PCIOCREAD, it only allows reading of PCI registers, so the question there is whether there are any potential security implications to allowing non-root users to read PCI registers. If reading configuration registers caused performance degredation, for instance. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DMA to user process address space!!!
On Thu, Nov 23, 2000 at 22:22:29 -0800, Mohan Krishna P wrote: AFAMUG, all user processes are allocated from the virtual memory. so DMA to that doesn't make sense. but is there some way, i can let the kernel know i am DMAing to an address location and hence keep it in main memory until some x seconds?? here is why we need this. we are writing software for a multi-port switch. it can be used in both managed and unmanaged modes. in managed mode, switch is connected to host through PCI interface. all packets that can't be switched are sent to host. with cach such packet, switch passes information like the source port of the packet, it's priority level, whether the packet is tagged or not etc. in normal operation, driver discards this information and sends the packet to ether_input(). for testing purpose, we would like to have user-level process, which receives packets bypassing the ip stack(it isn't freeBSD way of doing things, but this is only for testing) and verifies the information. if the above thing can't be done, then we will have to move the user-process functionality to driver. You can do what you're proposing, although it isn't clear that that would necessarily be the best thing to do. There are ways to map memory from the kernel's address space into a userland process address space and vice versa. Just for reference, the pass(4) driver maps things from userland into the kernel with the cam_periph_mapmem() function call in sys/cam/cam_periph.c. There are limits on the amount of data that can be mapped into the kernel with that approach. (128K, which is MAXPHYS) Another way to do get userland memory into the kernel is to map it copy on write. You can get kernel memory into userland via page flipping, if the pages are allocated in the kernel in a manner that allows them to be thrown away. Examples of COW (copy on write) mapping and page flipping are available in the code described here: http://people.FreeBSD.org/~ken/zero_copy Page flipping could also be used to get memory from userland into the kernel, although in that case it might need to be a page trade, unless the userland process was designed to never touch that chunk of memory again. One thing about mapping things COW or page flipping is that you can only do that with page-sized chunks of data. Since you are only passing packets into userland for testing purposes, it may not be necessary to have the high performance (or the page size and alignment issues) that you would gain from one of the methods I described. You can probably get by just as well designing a simple character device interface with a poll() routine that would allow you to select(2) on the file descriptor from a userland process, and wake up whenever a packet arrives. Then your driver can just use copyin(9) and copyout(9) to move things back and forth from the userland process into the driver. As you mentioned, another alternative is to implement the test functionality in the driver. Then you wouldn't have to worry about the performance or alignment considerations of moving things between the kernel and userland. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: zero copy TCP
On Tue, Nov 14, 2000 at 09:37:35 -0400, Jeroen C. van Gelderen wrote: "Jin Guojun (DSD staff)" wrote: I heard that zero copy TCP is already in FreeBSD, isn't it? I could not find any information in searching the entire website. Before I am going to spend some silly time working on it, I would like to know what is the status for "ZERO COPY TCP" in FreeBSD right now. If it already exists, how can I enable it (for 1500 MTU, not Jumbo Frame)? or someone is still working on it. http://people.freebsd.org/~ken/ http://people.freebsd.org/~ken/zero_copy/ FWIW, I just put up a new snapshot. All known bugs are now fixed. :) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
On Mon, Nov 13, 2000 at 08:51:37 -0600, Robert Lipe wrote: Kenneth D. Merry wrote: What does your driver do? It's not a driver as much as driver infrastructure. To measure the difficulty of porting the UDI Reference Implementation (available source soon!) I decided to try porting it to an OS that I knew little about. Ahh. UDI has a concept somewhat like that expressed in the core BSD bus enumeration code where you have a bus/bridge driver that enumerates children (additional busses or cards) which may each enumerate additional children. It looks like the normal BSD interfaces to the PCI bus assumes that I am one of those children. This is understandable and has parallels in UDI-land. What I really want is to be able to walk the installed/supported busses for a chance to bind them to UDI drivers. So I don't really want to replace the existing tree-builder, I'd like to make something somewhat parallel to it. Alternately, if there's a standard interface to a system configuration database that stores this tree, I could walk that table and hand that information to my bridge driver. UnixWare (resmgr), HP/UX (cdio) , and AIX (can't recall the name of it) have such interfaces. That is probably the direction you want to go in. We've got a device infrastructure already (new-bus), which is probably what you want to use. If you probed and attached UDI devices apart from new-bus, you'll probably run into all sorts of resource conflicts. (cards with two drivers attached and stepping on each other...) Unfortunately I don't know much about new-bus, so I can't tell you how easy it would be to do what you want to do with it. (There are other folks on this list who do know, though.) I do know that we have the concept of probe priorities, so you could probably set up UDI to probe at a higher priority than the default system drivers, and therefore attach instead of the default FreeBSD driver for a given piece of harware. If you do need to get at the data, the easiest thing to do would be to un-staticize pci_devq (in pci.c), and include pci/pcivar.h in your program, to get the definition for struct pci_devinfo. I went down that path, but then got sucked into a morass of chained includes that didn't have an obvious end. It looks like pci_devq has most of the interesting information that I'm looking for. (Not suprising since I'm wanting to do with that data pretty much what pci.c is doing with it...) Yep. That's probably not the way to go for what you're doing, though. code. If this is a driver you're going to want to ship in source or module form, It is. I'd like the reference implementation to ship in source form. It currently make extensive use of modules. Cool, it'll be interesting to see the source. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
On Mon, Nov 13, 2000 at 00:44:10 -0600, Robert Lipe wrote:
I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
4.1.1 on IA32 and need help understanding the ways of your world. :-)
I'd like my project to look like a "normal" driver and use supported
interfaces, but I'll patch the core code if I need to.
I have a need to walk the PCI bus, gleaning PCI IDs and other data.
(Yes, I know a dozen reasons why to NOT do that.) What I *almost*
need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
that this is a private data structure (static, lots of dependencies on
private headers not in sys/..., etc) and therefore unavailable. I
considered calling the ioctl code myself from withing my driver, but
that seems too weird. I thought about shipping the data to myself by
way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver,
turns around and hands data to me on an ioctl) but that sounds like an
application to be punished.
Is there a "normal" way for a conforming driver to walk the busses,
pluck out bus number, slot number, device id, subsystem id, and all that
traditional stuff, or do I just need to carve up pci.c and build my own
interface to do it?
Well, it might help if we understood a little more about why you want to
look at all the devices on the PCI bus. There are certainly plenty of
reasons to do it, but there may be other/better ways to get the
functionality you need. (I've done it from userland, FWIW. I also
wrote the current PCIOCGETCONF code.) What does your driver do?
If you do need to get at the data, the easiest thing to do would be to
un-staticize pci_devq (in pci.c), and include pci/pcivar.h in your program,
to get the definition for struct pci_devinfo.
If this is an embedded-type project that's going to involve shipping
already-compiled code, I wouldn't worry too much about modifying the PCI
code. If this is a driver you're going to want to ship in source or module
form, we'll likely need to work out how you're going to do it (i.e. what
changes will go into the tree), so the module or driver will work when it
is loaded or compiled.
[ ...major numbers for loadable devices... ]
Someone who knows more about modules can answer that one...
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
On Sun, Nov 05, 2000 at 17:32:16 +0900, Daniel C. Sobral wrote: "Kenneth D. Merry" wrote: I think vmstat(8) might be a better fit than iostat. vmstat already displays kernel memory usage (-m), interrupt usage (-i), paging stats (-s), and zone allocator stats (-z). That's vmstat's problem, not a feature. :-) That kind of thinking is what led to Linux /proc. Since vmstat already has "kitchen sink" type functionality (i.e. a wide variety of uses), I think it would probably work better to put this new functionality there. If it's not vm-related, it shouldn't be listed by vmstat. Interrupts aren't vm-related either, yet vmstat displays them. iostat is also designed primarily for continuous output use -- displaying a line of stats every N seconds. vmstat is also designed for that in its That's the objection I raised to Mike. :-) I suggested systat, though that has it's problems too. Well, perhaps this stuff should go in its own utility, since it doesn't really seem to fit anywhere else. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
On Sat, Nov 04, 2000 at 11:52:35 -0800, Mike Smith wrote: I'm wondering if this should have its own program, rather than squat in on iostat ? Adding yet another program for such a trivial fragment of code seems kinda silly. If/when someone uses the other interfaces as well to get the full device tree extracted, that probably belongs elsewhere, but right now iostat is as good a place as any for this I think. I think vmstat(8) might be a better fit than iostat. vmstat already displays kernel memory usage (-m), interrupt usage (-i), paging stats (-s), and zone allocator stats (-z). iostat only displays cpu, tty and disk I/O. Since vmstat already has "kitchen sink" type functionality (i.e. a wide variety of uses), I think it would probably work better to put this new functionality there. iostat is also designed primarily for continuous output use -- displaying a line of stats every N seconds. vmstat is also designed for that in its default output mode, but most of the other displays I mentioned above are one-shot displays, like the rman code. So one more wouldn't hurt. The only thing that would recommend iostat for the rman code is the name, I think. (I/O ports, iostat, etc.) So, I'd like to request that you use vmstat instead of iostat. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: several NFS mounts within a filesystem
On Wed, Aug 16, 2000 at 19:47:52 +0300, Peter Pentchev wrote: /usr/n/ringrowl/root -maproot=root -network 192.168.1.0 -mask 255.255.255.0 /usr/n/ringrowl/usr -maproot=root -network 192.168.1.0 -mask 255.255.255.0 And the result of ``mountd -d -l'' is: Aug 16 19:36:35 ringwraith mountd[2956]: can't change attributes for /usr/n/ringrowl/usr Aug 16 19:36:35 ringwraith mountd[2956]: bad exports list line /usr/n/ringrowl/usr -maproot After this, showmount -e shows an exported /usr/n/ringrowl/root, and plain old mount shows something new: /usr now has a NFS-mounted flag. Am I right in thinking that the kernel won't let me export more than one subdir of the same filesystem? If so, how do I get around this? I really really really really do not want to repartition, and vnconfig is just barely an option.. though if there is no other way, I'll have to do it. I think you want the '-alldirs' option. e.g.: /usr-alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
On Wed, Aug 09, 2000 at 23:08:12 +0200, Theo van Klaveren wrote: Soren Schmidt wrote: -long story snipped- | Am I just doing it wrong, or should atapi-cd.c be patched to verify if the | buffer is in user space or in kernel space? If so, what function checks if | an address is in kernel space or in user space? If not, what am I doing | wrong? | | Here's another idea, the ata driver can read/write 2352 sector size | blocks directly, no need to use that ugly ioctl. You just have to | set the right blocksize, I could provide you with a function for | that, no more ioctl mess ;) That would be _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? Getting AudioFS to work with SCSI drives is non-trivial, if you want it to work with a wide variety of drives. The reason is that different SCSI CDROM vendors had (have?) different ways of reading CD audio data off the drive. If you just want it to work with MMC-compliant drives, it might not be that hard to implement. If you want it to work with more than just MMC-compliant drives (and there are a lot of them out there), it'll take a fair number of quirk entries and device-specific code to do it. For an idea of the variety of different drives out there, take a look at tosha or cdda2wav (comes with cdrecord). They handle most of the drives on the market. (Thus the reason I didn't put all the code in the driver to do it.) If you decide you want to tackle it, let me know. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
On Thu, Aug 10, 2000 at 08:48:50 +0200, Soren Schmidt wrote: It seems Theo van Klaveren wrote: | Here's another idea, the ata driver can read/write 2352 sector size | blocks directly, no need to use that ugly ioctl. You just have to | set the right blocksize, I could provide you with a function for | that, no more ioctl mess ;) That would be _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? I dont think the SCSI/CAM system can cope with != % 512 byte blocks, so you are out of luck there, but then again SCSI/CAM doesnt support CDIOCREADAUDIO either, so you are not worse of than now :) True enough, the cd(4) driver uses whatever blocksize the drive returns in response to a read capacity command. (And that is generally either 2048 or 512 bytes.) As for the CDIOCREADAUDIO ioctl, as I mentioned to Theo in a previous message, there are a wide variety of methods that SCSI CDROM vendors have used to get CDDA data off the disks. Thus the reason I've left support for CDDA extraction to external programs like tosha and cdda2wav. :) Neither one of those obstacles is insurmountable, but they will make it more difficult to support something like AudioFS with the SCSI CD driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Gigabit ethernet
On Wed, Aug 02, 2000 at 09:15:00 -0700, Josef Grosch wrote: Simple question: Which Gigabit ethernet card works best with FreeBSD? Alteon-based boards. This includes Alteon ACEnics, the 3Com 3c985B (which has 1MB SRAM), and the Netgear GA620 (which has 512K SRAM). You can get the Netgear board for about $320, and the copper version of the board for about $310 from www.necxdirect.com. The 3Com board is about $680 from the same place. (You're paying for the extra memory, which can make a difference, albeit not an enormous difference. Also, the Windows drivers for the Netgear boards don't do jumbo frames. I'm not sure whether the 3Com Windows drivers do jumbo frames, but I would guess that they do.) If you want bandwidth numbers, see: http://people.freebsd.org/~ken/zero_copy/ Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Gigabit ethernet
On Wed, Aug 02, 2000 at 13:17:51 -0400, Essenz Consulting wrote: Do both the Netgear GA620 and GA620T work? The 620 (i.e. the fiber version of the board) definitely works, I've got two. I would assume that the 620T works, although I don't have any of those. If it is like the ACEnic, it should work with the driver in -current, although you might need to add a new PCI ID to the driver. (The 1000BaseT version of the ACEnic has a different PCI ID.) It won't work with -stable until the new firmware and driver changes get merged in. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 840 Chipset Discontinue
On Fri, Jul 21, 2000 at 12:31:58 -0400, Essenz Consulting wrote: I was told by several of my distributors that all motherboards based off of the Intel 840 chipset are being discontinued. That means the Supermicro PIIDM3 and PIIIDME, and any other 840 board. Are you sure they don't just mean any 840 board that uses SDRAM? It looks like Supermicro has a RAMBUS 840 board on their web page now: http://www.supermicro.com/PRODUCT/MotherBoards/840/PIIIDR3a.htm Supermicro has two new boards, 370DL3 and 370DLE. Identical in specs to the 840 boards, but using some kind of "ServerWork LE" chipset. However, I have also been hearing bad news about these boards as well. Not quite identical. They don't have AGP, which makes it difficult to get graphics boards. (If you want to use it for a workstation. Most graphics boards don't come in plain PCI anymore.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 160/m support...
On Tue, Jul 11, 2000 at 16:39:15 -0400, Essenz Consulting wrote: Just curious, This has probably been asked before, but.. Is Adaptec aic-7892 and 7899 160/m SCSI support in the pipeline to be worked on? aka, has adaptec released any info to those FreeBSD team members who work on the SCSI drivers? Is it possible that maybe within the next 4 months 160/m support will exist in FreeBSD 4/5? It's working, but isn't in the tree yet. You'll need to ask Justin Gibbs [EMAIL PROTECTED] if you want any more information... Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max DMA size
On Thu, Jul 06, 2000 at 15:51:34 -0400, Zhihui Zhang wrote: Can anyone tell me what factors determine the max DMA size (DMA counter on each controller or PCI bus related)? What is the typical max DMA size for a SCSI disk connected to a PCI bus? It seems to be much larger than MAXPHYS (128K). If so, does it mean we are not using full potential of DMA? So what's the problem if we enlarge MAXPHYS? Any help is appreciated. MAXPHYS determines the size of struct buf, which at the moment determines the maximum size of a given DMA transaction to a SCSI controller. Typical modern SCSI controllers can handle much more than MAXPHYS data (currently 128K) at a time. An exception is the Adaptec 154x controllers, which can only handle about 64K of data. (Thus the reason I/O through the CAM passthrough interface is limited to 64K instead of the full 128K. We will have that limitation until we implement a way of determining the maximum DMA size allowable for a given controller.) However, as Matt said, you have to be careful about increasing MAXPHYS too much, since you could end up allocating too much memory. I think a better approach to increasing the amount of data that can be sent at one time to a SCSI controller would be to implement some sort of buffer chaining scheme. Most SCSI controllers can do scatter/gather DMA, and CAM has facilities for it, so that would probably be the easiest way to go. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf re-write(s): v 0.2: request-for-comments
On Wed, Jun 28, 2000 at 12:00:50 -0400, Andrew Gallatin wrote:
Dennis writes:
Its not really "wonderful" to those that have already implemented something
using the old method.
Speaking as somebody who maintains 3 out-of-tree network drivers a
bunch of local code, all of which makes heavy use of external mbufs, I
certainly consider it to be "wonderful."
What version is this "patch" likely to find its way into the mainstream
code (or will it), as its likely to break our drivers.
I presume that the reason it is being presented here is to collect
input. This input may influence the patch. I would imagine that it
would go into 5.0-CURRENT first.
At any rate, you might not need to make changes to anything other than
your function prototypes, depending on how your ext_free and ext_ref
functions are implemented. He's basically changed the second arg of
those functions to take a void * which nobody else is going to look
at, so you can cast it to an int use it as a simple counter or use
it as a pointer to a private data structure if you need more state.
Currently, that second arg is the ext_size, which was always pretty
useless (at least for me..).
FWIW, I'm in favor of a pointer argument as well. The way I implemented it
was actually with a third argument, instead of changing the int to void.
i.e.:
/* description of external storage mapped into mbuf, valid if M_EXT set */
struct m_ext {
caddr_t ext_buf;/* start of buffer */
void(*ext_free) /* free routine if not the usual */
#ifdef EXTRA_MBUF_ARG
__P((caddr_t, u_int, void *));
#else
__P((caddr_t, u_int));
#endif
u_int ext_size; /* size of buffer, for ext_free */
void(*ext_ref) /* add a reference to the ext object */
#ifdef EXTRA_MBUF_ARG
__P((caddr_t, u_int, void *));
void*ext_arg;
#else
__P((caddr_t, u_int));
#endif
};
I don't feel too strongly about it either way -- I suppose it's about the
same amount of work to port older code. (I just put an ifdef in the
sendfile code, which doesn't use the third argument in my tree.)
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI HBA device detection?
On Fri, Jun 23, 2000 at 13:10:26 -0400, Nat Lanza wrote: I'm writing a SCSI HBA driver that simulates a bus with some ramdisk-backed disks attached to it. I've read through the HBA tutorial in Daemon News, but I'm still unsure how to tell the system about my pretend disk devices. I suspect part of the problem is that I don't actually have real devices or a real IO bus. Anyone feel like explaining this? Well, when the system boots, it sends out a SCSI INQUIRY command to each target on each bus. Each target that responds and sends back inquiry data will get further along in the probe process. The same thing happens when you do 'camcontrol rescan 4' to rescan SCSI bus 4. You need to have your "disks" respond to the inquiry command with inquiry data, as well as have them respond suitably to the various other commands that CAM will send. The commands you'll need to support include (but are not limited to), inquiry, test unit ready, read capacity, read (6, 10 and maybe 12 byte), write (6, 10 and maybe 12 byte) and perhaps mode sense. Those commands will probably get you most of the way towards probing and attaching with the da(4) driver. Another alternative to a ramdisk-like driver is a target mode driver. There is a target mode processor target device in sys/cam/scsi/scsi_target.c that you can look at as an example. You'd be limited to the SCSI bus speed (40, 80, 160MB/sec) for throughput though. You'll need specific hardware (Adaptec or QLogic) to do it as well. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Path MTU discovery.
On Thu, Jun 08, 2000 at 18:03:45 +1200, Dave Preece wrote: Just learning about this: I can see the advantages but does anything use it? Sure, TCP uses it. TCP (at least in FreeBSD) sets the "don't frag" bit on all its outgoing packets. If the packet gets to a router with an outgoing MTU that is too small to hold the packet without fragmentation, the router is supposed to send back and ICMP message telling the source machine to use a smaller packet size. When the source machine receives the ICMP message, it will update the MTU for that route, and try sending packets out again with the lower MTU. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: i suppose the only place where you use the actual card names is the firewall config and rc.conf -- can't you just make these scripts fetch the ethernet address of the card(s), set a shell variable with the name of the good card, and go ahead with that ? Yeah I'm about to the point of doing this for lack of other options. Thanks for the sample code -- I'm sure it'll come in handy if I can solve this any other way. The best fix would be to find a way to hard-wire which card is which in the kernel config (ie fxp0 is always on pci0...) but I dont know if you can do that kind of thing with pci devices. The problem is that when the new-bus code was introduced, the probe order was changed from a bus-by-bus probe (breadth first?) to a depth-first probe. i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is probed, rather than deferring the probe of the new bus until the probe of the current bus has been completed. I think Doug Rabson had plans to fix the probe order, but it never happened. There is no way to hardwire PCI devices, so you'll probably have to just change which card is referenced in your scripts. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Supermicro PIIIDM3 Problems...
On Mon, May 22, 2000 at 11:33:52 -0700, Mike Smith wrote: Can you be more specific about "panicing"? As far as details go, you're not helping yourself. I was doing a FreeBSD 4.0 Install on a fairly new Supermicro PIIIDM3 motherboard. I eventually got FreeBSD 4.0 installed, however, during the install, it kept hanging up and panicing. After trying to do a bin only install, it took about 7 trys until it didnt hang up and panic. When I did get it installed, everything worked, and it booted. But if I go into sysinstall and try to do a post install addition of, lets say src/sys, same thing happens. It freezes up and hangs part way throw, and eventually will throw up a panic error. Any ideas about the stability of the aix78xx driver for this motherboard and it's aic-7892 chip? I use one of these boards on a daily basis; it's been very stable under both -stable and -current, although I don't use the SCSI interface very often anymore. Well, one question is whether or not you have ECC memory in the machine, and if so, if you have parity checking or ECC turned on. Mike's board doesn't have ECC memory, and I've been trying to find someone with a SuperMicro 840 board with ECC turned on. (To see whether their boards have the problem with the MRH-S chip.) As far as the 7892 chip, the driver should be pretty stable, I don't think other folks have had trouble with it. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JetDirect 500X and FreeBSD
On Sun, Apr 02, 2000 at 13:52:12 +1000, Andrew MacIntyre wrote: On Fri, 31 Mar 2000, Jeremiah Gowdy wrote: Does anyone have any experiance or information about using HP JetDirect 500X Printer Hubs with FreeBSD ? This is mission critical for my company, so any information greatly appriciated. These things have an LPD server built in IIRC, so your could just configure them as a remote LPD printer in /etc/printcap. However, I've not been totally satisfied with some of HP's earlier attempts at LPD support in JetDirect cards for their lasers printers, as they weren't particularly reliable, particularly when multiple jobs were queued simultaneously. I hope their more recent stuff is better behaved. You might want to check out LprNg or CUPS to see whether they support the native HP protocol (on port 9100???) if your box doesn't seem to cope, so that one box can be the "print server" and thus serialize all the jobs. We do this at work, although in that case NT is providing the "print server" function. You can setup the stock FreeBSD lpd to talk the native HP printer protocol to a HP printer with a Jet Direct card. I've got the following setup on a -current box that talks to my HP LaserJet 4000 (hostname is "printer"): in /etc/printcap: lp|ps:\ :mx#0:lp=9100@printer:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:sh:\ :if=/usr/local/lib/filters/inputshell:\ :of=/usr/local/lib/filters/ofhp: /usr/local/lib/filters/inputshell is just this: #!/bin/sh /usr/local/lib/filters/ifhp -Ttbcp=on,model=5M exit 0 The ifhp/ofhp comes in the ifhp port, which is ports/print/ifhp. The above setup works well with either text files or postscript. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mylex Support
On Sat, Mar 25, 2000 at 16:26:32 -0500, Colin wrote: A friend of mine (FreeBSD user, between ISP'S) would like to know if anybody is working on support for Mylex Flashpoint BT950. He has one and is willing to port the driver from either Linux or BSDI, but is unwilling to duplicate the effort if someone else already has this beast in hand. Thanks for your comments. You should talk to Justin Gibbs [EMAIL PROTECTED]. He has the hardware, and I think he has documentation, and he has been planning on doing a driver for a while. He hasn't gotten around to it yet, though, so he might be open to someone else doing a driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to read a file from a device driver?
On Fri, Mar 17, 2000 at 23:59:28 -0500, Matthew N. Dodd wrote:
On Fri, 17 Mar 2000, Gary T. Corcoran wrote:
I'm trying to initialize a network device, and I'm trying to download
code *into* my device from some binary system files. There is no
"user space" or user process, for that matter, to deal with at this
point. I just want to (at this step) open a file(s) directly from my
device driver, read the file(s), and download the relevant parts to my
device.
There isn't really any clean way of doing this so most drivers that need
to load firmware usually compile them in. :/
True enough. The Alteon Tigon driver (sys/pci/if_ti.c) decides which one
of its firmware images (sys/pci/{ti_fw,ti_fw2}.h) based on the chip
revision.
So that's one possible example to look at.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: specifying probe order for scsi controllers
On Tue, Mar 14, 2000 at 21:47:53 -0800, dannyman wrote: so, i have a production system with an ncr0 to which i would like to add an aha0 in addition to the existing controller. when i do this, though, the aha0 comes up before the ncr0, so the numbering on the system disk gets thrown off. i tried changing the fstab entries for the system disk, but the slices for da1s1 weren't MAKEDEV'ed and apparently you can not MAKEDEV the slices within the partition ... perhaps that is because my existing da1 is a dedicated disk? nyways, can I specify the order in which these controllers come up in the system? i had guessed that you could based on the admonition about ISA ethernet probe orders ... but by default the ncr0 is listed first. or is there some way i can config things to keep da0 on the ncr and da1 on the aha? Yes. See src/sys/i386/conf/LINT. The section on SCSI devices describes how to wire down disks. The scsi(4) man page also has information on wiring down devices. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel fxp network chip, unknown PHY 17 type 2
On Thu, Mar 09, 2000 at 18:11:58 +, Roger Hardiman wrote: David Can you look on the motherboard and find out what type of chip it uses? It should be one of: 82557, 82558, or 82559. Let me know. The lid is off. It says GD82559 I wonder if we can get Jordan to allow a quick commit fix for this one. The board (from SuperMicro) is a top end server board. Is this one of their SDRAM i840 boards? Does it have the memory corruption bug with the MRH-S? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: open ref counts in CAM and vn
On Thu, Feb 03, 2000 at 10:26:15 +0100, Guido van Rooij wrote: A collegue fo mine had the problem that it was possible to vnconfig -u a vn device that was currently in use. This strikes me as odd. When looking through the da device code, I notice a similar problem. Suppose I have a zip fdisk mounted with a disklabel and 2 ufs partitions on it. When I mount both partitions, the disk will be locked. But it will be unlocked at the first unmount. I guess there should be a refcounter that keeps track of the amount of opens and only unlock devices at the last close. Same for vn.c. Any comments? The reference counting should be handled by PHK's disk layer (which sits above CAM), and the da driver's close routine should only get called on final close. I don't know about the vn device, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Thu, Feb 03, 2000 at 10:50:32 -0800, Matthew Jacob wrote: The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. That's not memory- that's FIFO- there are two of them, I believe, one for receive, the other for xmit. You can devote 64k to ring descriptors for receive- that's 4096 descriptors- each able to manage a 2k buffer. And you can have two receive rings. You can have the same size for xmit. So, the receive performance bottleneck for this chip/board will be in how good your PCI implementation is at first followed by how low an amount of interrupt latency for reinstruct. If your PCI implementation can keep up with Gigabit speeds, you're fine. If not, I'm not sure that 512K or 1MB buffering buys you much. I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Thu, Feb 03, 2000 at 11:23:45 -0800, Matthew Jacob wrote: I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. Yes, but that's what having 8192 2KByte descriptors handy is for... (that's 16MB of buffering). Are those all in card memory, or in host memory? What happens when you've got some other traffic on the PCI bus, and the card gets a little behind in DMAing its data into host memory? If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Typically I don't see higher than 60 or 70MB/s real throughput on most systems. I've seen 100MB/sec on Pentium II 450's (440BX), and 90MB/sec on Pentium II 350's (440BX). Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
[ Thanks for the info Bill! ] On Thu, Feb 03, 2000 at 21:29:27 -0500, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: The Netgear GA620 is a 512K Tigon 2 board, and generally goes for around $300 or so. The 3Com boards have 1MB of SRAM, but I'm not sure whether they're Tigon 1 or Tigon 2. You really want a Tigon 2 board. Maybe someone who has one can comment. The original 3Com 3c985 was a Tigon 1 board (I have one) and the 3c985B is a Tigon 2. The Tigon 1 is no longer in production, though of course I try to maintain support for it for those people who still have them. The Tigon 1 had only a single R4000 CPU in it while the Tigon 2 has two. Ahh, that's good to know, I was wondering whether they had a Tigon 2 board out, since it would make a cheaper alternative to the 1MB ACEnic. The Netgear GA620 is by far the cheapest at about $320. The various OEM cards sold for the PC are usually around $600, give or take $100. The GA620 only has 512K of SRAM compared to 1MB on most of the others, however you're not likely to notice a problem with that unless you try to push the card really hard with a really big TCP window size and jumbo frames. That has been my experience as well. The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. Even with the 512K Alteon boards, you have a minimum of about 200K, and probably more like 300K of cache for transmit and receive. The Alteon cards also need a certain amount of SRAM to run the firmware. Yep, thus the 200K-300K number. The minimum amount of buffer that the board will configure is 64K for transmit buffers and 128K for receive buffers. It looks at the size of the firmware and associated data structures, and allocates the rest of the card memory for transmit and receive buffer space. Both the Alteon and SysKonnect NICs are 64-bit PCI cards. (Actually, I'm pretty sure all of the PCI gigabit NICs are 64-bit.) Both kinds of cards can do jumbograms on FreeBSD. Also, both vendors have released pretty good hardware documentation, which makes them good choices for custom applications, if you're into that sort of thing. Alteon also provides firmware source, which can really come in handy. Do you know if SysKonnect has released firmware? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-specific extension of struct mtget breaks dump(8) from Solaris
On Tue, Feb 01, 2000 at 23:28:17 -0800, Matthew Jacob wrote: rmt(8) returns the result of MTIOCGET filled into struct mtget in response to the 'S' command, issued by dump(8) of some certain OSs including Solaris. (FreeBSD's one seems to not issue the 'S' command) Due to the extention made to struct mtget in FreeBSD, remote dump from, eg Solaris to FreeBSD fails to establish rmt connection. Maybe we would have to provide something like struct mtget_org for compatibility with other OSs. Also, if we were to issue 'S' in our dump(8), some command extention may be required. (any plans?) Any comments? Yes. This is definitely an issue. Didn't this come up before and was a PR filed that I somehow forgot to own? After all, I probably broke things. I wonder if this has been broken for a long time, likely by the FreeBSD-specific things in struct mtget. (They first show up in rev 1.2 of mtio.h, and were likely from the 386bsd days.) It would be nice if it worked between systems, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Wed, Feb 02, 2000 at 15:11:16 -0700, Wes Peters wrote: "Kenneth D. Merry" wrote: On Wed, Feb 02, 2000 at 13:03:09 -0500, Thomas Stromberg wrote: We're currently looking at upgrading several of our FreeBSD servers (dual PIII-600's, 66MHz PCI) and some Sun Ultra's to Gigabit Ethernet. We plan to hook these machines into our Cisco Catalyst 5000 server. They will most likely move to be running FreeBSD 4.x by the time that we actually get our budget approved. What experiences do you guys have with the cards? I would recommend getting Alteon boards. It is likely that the Sun boards are Alteon OEM, although I'm not positive. One thing to keep in mind is that both Netgear and 3Com are OEMing Alteon boards, and you'll get them much cheaper that way. The boards are pretty much identical to the Alteon branded boards (which have no identifying marks on them). The performance is the same, at least for the Netgear boards. (I don't have any 3Com boards.) The Netgear GA620 is a 512K Tigon 2 board, and generally goes for around $300 or so. The 3Com boards have 1MB of SRAM, but I'm not sure whether they're Tigon 1 or Tigon 2. You really want a Tigon 2 board. Maybe someone who has one can comment. I have a couple of GA620's here, too, and they work quite well. They support both 66Mhz and 64-bit PCI bus. We paid $329 from warehouse.com about 4 months ago, quite a reasonable price. You might want to look around and see if anyone has Solaris drivers for the Tigon-2, if you're using PCI Sun machines. Alteon includes a Solaris driver in their driver development kit. It might be possible to modify the probe routine to recognize other Tigon boards like the Netgear or 3Com boards. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Wed, Feb 02, 2000 at 13:03:09 -0500, Thomas Stromberg wrote: We're currently looking at upgrading several of our FreeBSD servers (dual PIII-600's, 66MHz PCI) and some Sun Ultra's to Gigabit Ethernet. We plan to hook these machines into our Cisco Catalyst 5000 server. They will most likely move to be running FreeBSD 4.x by the time that we actually get our budget approved. What experiences do you guys have with the cards? Currently we're looking at the ~$1000 range, specifically at Alteon 512k's ($1000) for the FreeBSD servers and Sun Gigabit 2.0's ($2000) for the Sun servers. I was interested in the Myrinet cards (for obvious reasons), but they appear to require a Myrinet switch (though I found myself slightly confused so I may be wrong) rather then being able to hook into our Catalyst 5000. The Intel PRO/1000 Gigabit cards look rather nice too, but I haven't seen drivers yet for FreeBSD (Linux yes). I'm pretty much purchasing on marketing and reputation rather then any experience here, so any help would be much appreciated. I would recommend getting Alteon boards. It is likely that the Sun boards are Alteon OEM, although I'm not positive. One thing to keep in mind is that both Netgear and 3Com are OEMing Alteon boards, and you'll get them much cheaper that way. The boards are pretty much identical to the Alteon branded boards (which have no identifying marks on them). The performance is the same, at least for the Netgear boards. (I don't have any 3Com boards.) The Netgear GA620 is a 512K Tigon 2 board, and generally goes for around $300 or so. The 3Com boards have 1MB of SRAM, but I'm not sure whether they're Tigon 1 or Tigon 2. You really want a Tigon 2 board. Maybe someone who has one can comment. The Intel cards may look nice, and there is a FreeBSD driver for them, but I wouldn't get one. The first problem with the Intel boards is that there are no docs for them. Supposedly they're using a Cisco chip, and the specs for the chip are top secret. The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. Even with the 512K Alteon boards, you have a minimum of about 200K, and probably more like 300K of cache for transmit and receive. The Intel boards also don't have the features necessary to really support zero copy TCP receive. The Alteon boards, on the other hand, have most of the features necessary, and if I get some time, I may add the last feature (header splitting) to the firmware. The other alternative is SysKonnect, and that might actually be a good alternative. I haven't seen the boards, don't know how much they cost, etc. etc. You might want to ask Bill Paul about them, he wrote the driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsiformat
On Sat, Jan 29, 2000 at 21:55:57 +0100, Christoph Kukulies wrote: I have a block on a SCSI disk (Fujitsu M2954S-512 ) which I cannot write to - fsck hangs eternally. Besides from trying the SCSICNTL utility from Adaptec (which I had to boot off of a DOS floppy) is there a way of formatting a drive from being booted under FreeBSD? E.g. by sending a sequence of approriate commands to the scsi bus? You can do it with camcontrol(8), see the examples section in the man page for the command. I've also written code to implement 'camcontrol format', but I have gotten very little feedback on it in 8 months or so. Would you like to test it? It is located here: http://www.FreeBSD.org/~ken/camcontrol.format.2116 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 13:31:23 -0600, Jonathan Lemon wrote: On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote: We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a bit nervous because the 2400 uses a non-Intel server chipset made by a company called RCC Reliance. The chipset is called the "LE-64 ver 3.0". and I cannot seem to find any info about it. The most I've been able to turn up is somebody else looking for info. I was wondering if anybody was currently using a PowerEdge 2400 (or any other server products with this PCI chipset) with FreeBSD So -- does FreeBSD work with RCC chipsets? Is the chipset robust reliable? We've been badly burned a few times by buggy DEC PCI chipsets we're hoping to not repeat the experience with an x86 ;-) It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? This is with a RCC-186566-PO3. As for stability, I have another box running Linux with an RCC--PO2 that seems fairly stable. The RCC chips are supposed to allow better memory bandwidth @ 133Mhz. Anyone have a URL for RCC? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote: On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? Oops, you're right. That's probably the onboard Adaptec 7899. Yep, it is. I missed the 7899 ID when looking through the Adaptec driver. If you get the latest Adaptec driver in -current, you should be able to use that chip at Ultra2 speeds. The RCC is probably this one: pci: unknown ATA vendor = 0x1166, device = 0x0211 I wonder why it flags it as a ATA device, I'm pretty sure this is the RCC chip -- the vendor id matches. (I checked this time.) It's proably the chip class or something. That could well be an IDE chip, though. Intel's chipsets usually include an IDE controller. Does anyone have a URL for "RCC"? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdrecord Pioneer DVR-S201?
On Thu, Jan 06, 2000 at 00:39:35 -0500, John W. DeBoskey wrote: Hi, The subject pretty much asks the question. I'm looking for anyone who has used or tried to use the new Pioneer DVR-S201 2nd Generation 4.7GB DVD-Writer on FreeBSD/cdrecord. I've looked at the current cdrecord support page and I don't see this drive listed. I've also search deja for any references to this drive and cdrecord and could not find any. From perusing the cdrecord pages, it looks like it should be possible to simply create a very large iso9660 filesystem and then burn it... Basically, a really big cdrom. I'm currently only interested in disk-at-once writing. The main question is probably what interface does the drive use? Does it use the same sort of write/fixate process that CD-R's use? DVD-RAM drives use a standard read/write interface, but they're more like a standard optical drive in interface. My guess is that it acts kinda like a CD-R, but it's hard to say without specs of some sort. I'd suggest that you contact Joerg Schilling [EMAIL PROTECTED] and see what he has to say about it. He may ask for at least a loner drive and specs from Pioneer in order to support it. If it does use the standard read/write interface, and not a CD-R type interface, let me know, and I can probably get you up and running. BTW, the suggested retail price is amazingly high -- $5400. I suppose it could be to discourage people from copying movies, or it could just be because it's the only DVD-R drive on the market. (is it?) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
On Thu, Dec 16, 1999 at 00:49:47 +, WHS wrote: Thomas David Rivers wrote: The kernel hangs (rather an endless loop) with messages like: ncr0: timeout nccb=0xc0c38000 if I attach a fujitsu M2513A2 640MB MO drive. From a quick glance in the ncr source it seems there's a problem with the script stuff in case of a timeout. Anyway, this doesn't happen with either the obsd or linux ncr driver (both derived from the fbsd one I believe), so that may provide some info for whoever maintains this driver. Please mail me with suggestions or pacthes to try out as I need the MO drive. Regards, Wouter You didn't say which version of FreeBSD you're using Oops.. It's 3.3 (RELEASE I guess, the oct cdrom). Depending on what sort of NCR board you have, I would suggest trying out the new sym driver, written by Gerard Roudier [EMAIL PROTECTED]. It is located here: ftp://ftp.tux.org/tux/roudier/drivers/freebsd/experimental/ Look at the readme file in that directory to determine whether your board is supported. If you have questions, problems, etc., with the sym driver, contact Gerard. In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
On Thu, Dec 16, 1999 at 02:03:10 +, W.H.Scholten wrote: Kenneth D. Merry wrote: In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. I'm using a Tekram DC 390U (ncr 875 ultra, not wide) controller which the readme said was supported, so I just compiled a new kernel with the new driver and everything works hunky dory now :-) Good, glad to hear it! Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
Greg Lehey wrote... On Monday, 15 November 1999 at 15:13:53 -0700, Kenneth D. Merry wrote: Zhihui Zhang wrote... I have set up a remote debugging environment. But I think default 9600 bps is slow. I can use "set remotebaud 19200" on the debugging machine side. How can I set the baud rate on the target machine that is running the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find no command to set the baud rate). Any help is appreciated. Use the CONSPEED option in the kernel config file on the target machine. e.g.: options CONSPEED=115200 I'm planning to modify ddb to specify the bit rate as a parameter to the gdb command: db gdb 19200 Next trap will enter GDB remote protocol mode at 19200 bps Comments? It might also be nice to have it tuneable as a kernel variable from the loader and a sysctl variable. Oh, I see it's already available as the 'machdep.conspeed' sysctl variable. Obviously, specifying the baud rate at the ddb prompt should override any previous baud rate setting. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Use remote debugging on 3.3-Release
Zhihui Zhang wrote... I did a little remote debugging with serial cable on 4.0-current a while ago. But now I can not make it work on 3.3-RELEASE. I have used kermit to make sure that the cable connection is good. I also have added necessary kernel options into the configuration file. My questions are: (1) What flag should I use with sio0. FreeBSD-current uses 0x80. What should I use with 3.3-RELEAE? I have tried 0x40. I use 0x50 with -stable, and 0x80 with -current. Annoying, but it seems to work. (the stable in question isn't a up-to-the-minute version of -stable, though) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ahc (2940UW) driver in 3.3
Darren Reed wrote... Some time ago I reported corruption using 2.2.8 with an DDRS-39130 connected to a 2940UW. I've done some testing today with 3.3, on a totally different box, with a brand new scsi cable (never before used). Still I see corruption. It's not in the same place every time. My test involves dd'ing /dev/zero to create a 300MB file and then outputting that file in hex, looking for non-zero bytes. What surprised me was it even passed a couple of times. Before I go blaming the drive, can anyone categorically confirm that parity is enabled and enforced in the FreeBSD driver for the 7880 ? For example, has anyone actually seen evidence that it handles parity errors ? Yes, it handles parity errors: (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x110 SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x110 SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 31 d9 80 0 0 4 0 (da0:ahc0:0:0:0): ABORTED COMMAND asc:48,0 (da0:ahc0:0:0:0): Initiator detected error message received That's from a mid-August -stable machine that most likely has a bad cable. I'm not sure, however, whether the driver pays attention to the parity setting in the Adaptec BIOS, or what effect that has on things. You should make sure that you have parity checking enabled in your BIOS. I haven't seen any corruption problems with the driver, and yours is the first report I've seen. Do you have parity memory, and is parity checking or ECC enabled? It may be unlikely for the same problem to happen on two different machines, but it is possible. Since the drive is the common element, I would be inclined to place the blame there. Do you have trouble with any other SCSI hard disks and the same machine/controller/cable combination? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
Randell Jesup wrote... This discussion should probably move to the freebsd-scsi list... "Kenneth D. Merry" [EMAIL PROTECTED] writes: Nick Hibma wrote... Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. If you're talking about polling for transaction completion in a device driver, my guess is that you're going to have to do things in an interrupt context. (Unless you use a kernel process to do it.) The thing to remember is that when you get CCBs down in a CAM device driver, it may well be in an interrupt context. You have to be able to deal with that. My guess is that it might be easiest to just use a timeout handler to poll the device for completion every so often. A kernel process may also be an option, depending on how nasty the device is. Ick. Polling == bad. Interrupts == good. This isn't a single- tasking OS ala Win9x. This goes double for SCSI drivers, which are inherently async and overlapped. I never said polling was good. Nick just asked about polling, and I commented on how it could be done. I have no idea why he wanted to know about polling, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
[ reply moved the bottom... ] Nick Hibma wrote... Warner Losh wrote... In message [EMAIL PROTECTED] Wilko Bulte writes: : How difficult would CAMifying a driver be? Speaking of which, has a "How to CAMify a driver" doc been written? Nope. You've CAMified a driver, would you like to write it? :) Ken While on the topic: What documentation is there for CAM? I've found the following, but would like to know whether there is more - CAM specification (at Digital?) www.t10.org, as Matt pointed out. FreeBSD/CAM is mostly CAM-2, with some CAM-3 thrown in. - justin's docu on freefall. Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. Well, first off, are you talking about polling for completion in a peripheral driver or a SIM/HBA driver? If you're looking to poll for CCB completion in a peripheral driver, there's already xpt_polled_action() and an example of how to use it in dadump() in scsi_da.c. If you're talking about polling for transaction completion in a device driver, my guess is that you're going to have to do things in an interrupt context. (Unless you use a kernel process to do it.) The thing to remember is that when you get CCBs down in a CAM device driver, it may well be in an interrupt context. You have to be able to deal with that. My guess is that it might be easiest to just use a timeout handler to poll the device for completion every so often. A kernel process may also be an option, depending on how nasty the device is. I would recommend talking to Justin about it. I'm sure he'll be glad to give you some recommendations on how to proceed. He's also not the only one who knows about this sort of stuff. By now, Matt Jacob has a reasonable amount of experience with CAM drivers and he may also be able to give you some advice. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Turbochannel based Alpha, quickie question
Wilko Bulte wrote... As Kenneth D. Merry wrote ... Wilko Bulte wrote... I have the distinct (bad) feeling this is due to: # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ncr0 controller isp0 #controller esp0 in GENERIC. I mean, esp is the driver for the 53C94 ncr scsi chip. Is there any particular reason why it is commented out in GENERIC? Floppy disk size limit maybe? The esp driver hasn't been ported to CAM. Are you volunteering? :) I noticed that when I tried to compile a TC-enabled kernel on my Aspen Alpine. Sort of familiar looking header files were missing ;-) Pre-CAM files obviously. Volunteering... if I could find the time. Unlikely.. Bummer. Is there a description somewhere how I can create my own test boot floppies? (I have a SCSI-interfaced floppy disk; works great BTW). I found write_mfs_in_kernel but the Makefile in /usr/src/release sort of escapes me in this respect (also in other respects to be honest..) You should probably look at the PicoBSD stuff. How difficult would CAMifying a driver be? Like the esp driver? I dunno. I haven't done it, so I can't say for sure. It looks like the esp-type chips don't have an on-board phase engine, so the driver has to do the work. So the driver behavior may be a little bit more complicated than a driver for a mailbox-type card. My guess is that it would be easier to write a TC front end for the amd driver. One other, perhaps easier task might be to write a TurboChannel front end for the AMD driver. Supposedly the AMD 53c974 and NCR 53C94 are pretty much the same chip. Sounds like one needs to dig into the TC idiosyncrasies. I'd rather not. I think that writing a TC attach routine for the AMD driver would be a good deal easier than porting the esp driver to CAM. It seems like the NCR 53C94 and AMD 53C974 chips are pretty similar. I tell you what -- if you're serious about getting this working, talk to me offline, and maybe I'll do the driver. I'd obviously need hardware, though, since I don't have any of the hardware in question. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Turbochannel based Alpha, quickie question
Matthew N. Dodd wrote... On Thu, 7 Oct 1999, Wilko Bulte wrote: # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ncr0 controller isp0 #controller esp0 in GENERIC. I mean, esp is the driver for the 53C94 ncr scsi chip. Is there any particular reason why it is commented out in GENERIC? Floppy disk size limit maybe? The 53c94 driver didn't make the CAM switchover. I've got EISA and MCA based 53c94 devices just waiting for a driver so I've some interest in seeing this fixed at some point. Well, you might want to look at what it would take to get the AMD driver working with that hardware. It might be easier than porting the esp driver to CAM. My guess is that the NetBSD esp driver would be a good place to look -- it supposedly works with AMD 53c974 chips as well as ESP chips and NCR 53c94 chips. So you could see what the differences are between the various chips there. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Turbochannel based Alpha, quickie question
Warner Losh wrote... In message [EMAIL PROTECTED] Wilko Bulte writes: : How difficult would CAMifying a driver be? Speaking of which, has a "How to CAMify a driver" doc been written? Nope. You've CAMified a driver, would you like to write it? :) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
[EMAIL PROTECTED] wrote... On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? [ ... ] See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. Well, I did not mean that has to be da0, da1, etc., but similar thing like dac0t0d0, dac0t1d0, ... dac3t4d0, etc. which is much clear what disk is. A few people does not like this one because the name is long, and it is like some commerical configuration. They said that this is Free software. You can pretty easily write a script to create device nodes named whatever you want. As long as the major and minor numbers are correct, you can call what would be /dev/da0a /dev/dac0t0d0a or whatever you like. I think it is possible, however, to come up with a somewhat reasonable naming scheme within the current framework. Manually wiring down disks is OK for a small set of hosts. 100+ hosts with two or three controllers with 100 TB disks will be terribly pain during the setup and maintenance. I would suggest that you come up with a standard naming scheme, and then use it across all of your machines. You could do something like: controller ahc0 controller ahc1 controller ahc2 controller scbus0 at ahc0 controller scbus1 at ahc1 controller scbus2 at ahc2 device da0 at scbus0 target 0 unit 0 device da1 at scbus0 target 1 unit 0 device da2 at scbus0 target 2 unit 0 ... device da14 at scbus0 target 14 unit 0 device da20 at scbus1 target 0 unit 0 device da21 at scbus1 target 1 unit 0 ... device da34 at scbus1 target 14 unit 0 device da40 at scbus2 target 0 unit 0 device da41 at scbus2 target 1 unit 0 ... device da54 at scbus2 target 14 unit 0 If you've got reasonably consistent controller hardware across the machines, you could use one wiring setup like the one above for all the machines. If you have different controller drivers on the different machines, you could probably just elminate the controller-bus wiring and go from there. You can design a maximal wire-down configuration for your largest machine, and it should just work on smaller machines. For instance, if your large machine has 7 SCSI busses and 15 disks per chain, you could set them up as da0 through da134 or so. The wiring configuration, though, would work even for a machine with one disk. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildfailure -current on Alpha?
Wilko Bulte wrote... On a freshly supped -current I get: location type 0 in non-PLT relocations ./make_keys /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/keys.list init_keytry.h /usr/libexec/ld-elf.so.1: /usr/obj/usr/src/tmp/usr/lib/libc.so.3: Unsupported relocation type 0 in non-PLT relocations *** Error code 1 1 error * I have no idea what a PLT-relocation is supposed to be ;-) Any other Alpha users seen this? I take it you haven't rebuilt world in the past few months? There was a change that went in in June, I think, that requires that you reinstall ld-elf.so.1 manually before you can buildworld on an Alpha. Kinda annoying, I think. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbufs, external storage, and MFREE
Matthew Dillon wrote... :I have the following question: Let's say that I have a block of user :memory which I've mapped into the kernel, and would like to send on a :network socket. I'd like to simply grab an mbuf, point to the memory as :external storage, and queue it up for transmission. This would work fine, :except that when MFREE gets called, I have to write an deallocator that :maintains a table of all the different cases where I've done this, and do :a reverse mapping back to the original block, and then deal with sending :more, unmapping, etc. In other words, having MFREE call a deallocator :with just the data pointer and the size is inconvenient (actually, it :would make my scenario quite inefficient given the number of mappings back :to the original block that would have to be done). : :Am I missing another mechanism to handle this? Does it not come up enough :to matter? : :-Chris This is almost precisely the mechanism that the sendfile() system call uses. In that case it maps VMIO-backed data rather then user memory, but it is a very similar problem. There has been talk of implementing this type of mechanism not only for sockets, but for file read()/write() as well. In fact, John Dyson had delved into the issue with his vfs.ioopt stuff before he ran out of time. The one problem with using direct VM page mappings is that currently there is no way for the socket to prevent the underlying data from being modified in the middle of a transmission. And, in the same respect for vfs.ioopt, no way to prevent the data the user ostensibly read() into his 'private' buffer from changing out from under the user if the underlying file is modified. How about marking the page copy-on-write? That way, if the user modifies the page while it is being transmitted, it'll just be copied, so the original data will be intact. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Wilko Bulte wrote...
As Kenneth D. Merry wrote ...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
The relevant code snippet is:
} else if (ccb-csio.scsi_status ==
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count
*/
panic("cam_periph_error: scsi status of "
"CHECK COND returned but no sense "
"information is availible. "
"Controller should have returned "
"CAM_AUTOSENSE_FAILED");
/* NOTREACHED */
error = EIO;
Even if we assume the scanner yelled for attention and/or the ncr
driver is at fault I don't really understand why the cam layer
decides to panic the machine. Wouldn't it be sufficient to return
EIO, or maybe just whine on the console?
Well, perhaps. My guess is that the intent was to catch problems with
incorrectly written device drivers. It looks like it may have caught a
problem in the NCR driver somewhere. I can't remember the rationale behind
having a panic instead of a printf at the moment.
IIRC I've seen systems report 'no sense' in their log files in situations
like this (non-FreeBSD systems that is). So I *guess* there are
SCSI devices out there that exhibit this behaviour..
Apparantly so. I sent Rene a patch to turn the panic into a printf. The
idea is that the error will get propagated back up, and we may be able to
get a better idea of just what is failing.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Rene de Vries wrote...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
Unfortunately the AIC7890 has a 68pin HD connector for which I don't have a
cable. As far as the scanner goes: I didn't expect it to have a decent SCSI
implementation, this is the reason I used a separate NCR810 to connect it to
my system. But I find it strange that the system panics on this
configuration, if something is wrong I expected the kernel to complain but
not panic (you could call a panic the ultimate way for the kernel to compain,
but this was not very helpfull). I'll try to get my hands on an
25 (Centronics) - 68pin HD cable (is there someone near Delft, NL that
has such a cable that I can borrow for a day or two?).
Whould it help if I took my old PC and installed FreeBSD 2.2.6 (the latest
2.2R i've got) and see what happens?
I'm not sure installing 2.2.6 would be that helpful, since it probably
won't exhibit the same behavior.
Here are some things to try:
- if you can, put the scanner on your 7890
- turn the panic statement into a printf
If you turn it into a printf, that may give us a better idea of just what
command is failing. The attached patch for cam_periph.c should do the
trick. The patch is against -current, but I think it should apply to
-stable okay.
I haven't checked to make sure it compiles or works, so you may have to
tweak it if it doesn't.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
//depot/cam/sys/cam/cam_periph.c#74 - /a/ken/perforce/cam/sys/cam/cam_periph.c
*** /tmp/tmp.25426.0Sun Sep 5 23:10:36 1999
--- /a/ken/perforce/cam/sys/cam/cam_periph.cSun Sep 5 23:10:02 1999
***
*** 1434,1445
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! panic("cam_periph_error: scsi status of "
"CHECK COND returned but no sense "
! "information is availible. "
! "Controller should have returned "
! "CAM_AUTOSENSE_FAILED");
! /* NOTREACHED */
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
--- 1434,1448
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! printf("cam_periph_error: scsi status of "
"CHECK COND returned but no sense "
! "information is availible.\n"
! "cam_periph_error: Controller should "
! "have returned CAM_AUTOSENSE_FAILED\n");
!
! retry = ccb-ccb_h.retry_count 0;
! if (retry)
! ccb-ccb_h.retry_count--;
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Rene de Vries wrote...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
Unfortunately the AIC7890 has a 68pin HD connector for which I don't have a
cable. As far as the scanner goes: I didn't expect it to have a decent SCSI
implementation, this is the reason I used a separate NCR810 to connect it to
my system. But I find it strange that the system panics on this
configuration, if something is wrong I expected the kernel to complain but
not panic (you could call a panic the ultimate way for the kernel to compain,
but this was not very helpfull). I'll try to get my hands on an
25 (Centronics) - 68pin HD cable (is there someone near Delft, NL that
has such a cable that I can borrow for a day or two?).
Whould it help if I took my old PC and installed FreeBSD 2.2.6 (the latest
2.2R i've got) and see what happens?
I'm not sure installing 2.2.6 would be that helpful, since it probably
won't exhibit the same behavior.
Here are some things to try:
- if you can, put the scanner on your 7890
- turn the panic statement into a printf
If you turn it into a printf, that may give us a better idea of just what
command is failing. The attached patch for cam_periph.c should do the
trick. The patch is against -current, but I think it should apply to
-stable okay.
I haven't checked to make sure it compiles or works, so you may have to
tweak it if it doesn't.
Ken
--
Kenneth Merry
k...@kdm.org
//depot/cam/sys/cam/cam_periph.c#74 -
/a/ken/perforce/cam/sys/cam/cam_periph.c
*** /tmp/tmp.25426.0Sun Sep 5 23:10:36 1999
--- /a/ken/perforce/cam/sys/cam/cam_periph.cSun Sep 5 23:10:02 1999
***
*** 1434,1445
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! panic(cam_periph_error: scsi status of
CHECK COND returned but no sense
! information is availible.
! Controller should have returned
! CAM_AUTOSENSE_FAILED);
! /* NOTREACHED */
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
--- 1434,1448
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! printf(cam_periph_error: scsi status of
CHECK COND returned but no sense
! information is availible.\n
! cam_periph_error: Controller should
! have returned CAM_AUTOSENSE_FAILED\n);
!
! retry = ccb-ccb_h.retry_count 0;
! if (retry)
! ccb-ccb_h.retry_count--;
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Wilko Bulte wrote...
As Kenneth D. Merry wrote ...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
The relevant code snippet is:
} else if (ccb-csio.scsi_status ==
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count
*/
panic(cam_periph_error: scsi status of
CHECK COND returned but no sense
information is availible.
Controller should have returned
CAM_AUTOSENSE_FAILED);
/* NOTREACHED */
error = EIO;
Even if we assume the scanner yelled for attention and/or the ncr
driver is at fault I don't really understand why the cam layer
decides to panic the machine. Wouldn't it be sufficient to return
EIO, or maybe just whine on the console?
Well, perhaps. My guess is that the intent was to catch problems with
incorrectly written device drivers. It looks like it may have caught a
problem in the NCR driver somewhere. I can't remember the rationale behind
having a panic instead of a printf at the moment.
IIRC I've seen systems report 'no sense' in their log files in situations
like this (non-FreeBSD systems that is). So I *guess* there are
SCSI devices out there that exhibit this behaviour..
Apparantly so. I sent Rene a patch to turn the panic into a printf. The
idea is that the error will get propagated back up, and we may be able to
get a better idea of just what is failing.
Ken
--
Kenneth Merry
k...@kdm.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Rene de Vries wrote... Hi, Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't want such a device on the same bus as my root disk which is on an aic7890). The kernel boots perfectly with both scsi adapters configured (as expected ;-), but as soon as the scanner is connected to the NCR810 the kernel panics. The scanner is the only device on that bus and termination is ok. The message is: "cam_periph_error: scsi status of CHECK COND returned but no sense information is availible. Controller should have returned CAM_AUTOSENSE_FAILED" (line 1441 of cam_periph.c). As far as understand the comments there, this means that the ncr810 driver did something cam did not expect. (This all happens during booting, at the time when the devices are probed.) For now I've connected the scanner to my other PC running W95 where its seems to work as expected. I hope someone can help me finding what the problem is and how to fix it. It sounds like there may be a couple of things going on. First, your scanner may not be returning sense information properly. Second, the NCR driver may be doing something wrong. It would be helpful if you could hook this up to your 7890 controller and see what happens. In general, the Adaptec driver behaves a little better than the NCR driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Rene de Vries wrote... Hi, Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't want such a device on the same bus as my root disk which is on an aic7890). The kernel boots perfectly with both scsi adapters configured (as expected ;-), but as soon as the scanner is connected to the NCR810 the kernel panics. The scanner is the only device on that bus and termination is ok. The message is: cam_periph_error: scsi status of CHECK COND returned but no sense information is availible. Controller should have returned CAM_AUTOSENSE_FAILED (line 1441 of cam_periph.c). As far as understand the comments there, this means that the ncr810 driver did something cam did not expect. (This all happens during booting, at the time when the devices are probed.) For now I've connected the scanner to my other PC running W95 where its seems to work as expected. I hope someone can help me finding what the problem is and how to fix it. It sounds like there may be a couple of things going on. First, your scanner may not be returning sense information properly. Second, the NCR driver may be doing something wrong. It would be helpful if you could hook this up to your 7890 controller and see what happens. In general, the Adaptec driver behaves a little better than the NCR driver. Ken -- Kenneth Merry k...@kdm.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [freebsdcon] radisson reservation
Bill Fumerola wrote... On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: I contacted radisson hotels for FreeBSDCon reservation with special discount, to get the following email - they don't know about special rate code "FreeBSDCon". What is the exact code for reservation? Do any of you have success experience with it? Use 'Walnut Creek CDROM' they know what that means. It would smart of FreeBSDcon to make sure before they put "just mention FreeBSD" that the hotel actually will respond to that. It took me 10 minutes of explanation for the reservation clerk to finally figure out just what the hell I was talking about. WC CDROM did the trick. I had a similar experience, and you're right, mentioning Walnut Creek seemed to work. Unfortunately, you have to call the local hotel to get reservations, and not the toll-free national hotline. The hotel in Berkeley doesn't have a toll free number, so after sitting on hold with the Berkeley Radission for 15 minutes, burning long distance money, I decided to call the national reservations hotline. They told me I had to call the reservations desk at the Berkeley Radission. Another thing I found out is that the reservations desk there is only open Monday through Friday (not sure about the hours). If you call on a weekend, the front desk people can't make the reservation because it's for a conference. Anyway, I was finally able to make the reservation, by calling on a Monday morning... (didn't have to sit on hold too long, thankfully) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
