Re: New BETA of Broadcom 440x chipset driver
Duncan, Duncan Barclay wrote: I think I have fixed the RX packet loss and memory corruption problems with the previous version of the driver. Please try the code at http://people.freebsd.org/~dmlb/bcm-0308252140.tar.gz this version works great! Would people please try this and feed back good and bad experiences. I would be interested if people could run their favorite net bench marks with the hw.bcm_rx_quick sysctl set to 1 (default) and 0. I didn't see a difference, but my router in the middle is the bottleneck. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: new routing protocol
Diomidis Spinellis wrote: I suggest you first build userland applications that emulate the kernel's networking behavior that affects your protocol. Build and test your protocol in userland on top of that environment, and once you are happy with it, plug it into the kernel. For example, you could use ns-2: http://www.isi.edu/nsnam/ns/ Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: GEOM Gate.
Bruce M Simpson wrote: On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: BTW, QNX had this for a long time, it's called QNet in there. Allows transparently to mount or use anything in /dev. Even a soundcard! Whatever next? PCI-over-IP? *shudder* Not new: http://www.isi.edu/div7/netstation/ Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: mixer for /etc/rc
On 3/18/2003 9:18 PM, Norikatsu Shigemura wrote: I want to mixer in /etc/rc (setting sound volume on boot). I add it to /etc/rc, /etc/defaults/rc.conf, etc... Would you review and commit? I have something like this locally, so I'd like to see it included (but I'm not a committer of course). Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Broadcom 440x support?
Hi, we just got an Asus P4PE board with a Broadcom 440x NIC on it - is there any driver that supports it yet? Thanks Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Packet length 1284 instead of 1280
Audsin wrote: Sir / Madam I am doing my research on fragmentation avoidance technique for mip6. I am using FreeBSD4.4 with kame snap and ethereal to capture packets I have a query regarding the packet length If i am correct , packet length = IPHdr +extHdr+TCPHdr+TCPOpt+Data =IPHdr+Routing Header + Frag Header + TCP Header+ Tcpopt+ Data 40+24+8+20+12+1176=1280 (Which is the MTU of the gif0 interface) But my ethereal capture says the packet length to be 1284 btyes. Can anyone please let me know what that 4 bytes is accounted for? Can't help you with your question, but if you're using 4.4-RELEASE, the KAME -SNAP you're using must be ancient. There have been many fixes, especially to the MIP6 code, so upgrading to a recent -SNAP may simply make the problem go away. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
anoncvs.freebsd.org reachability
Hi, for the last couple of days I've been unable to cvs update my sources, because anoncvs.freebsd.org is unreachable: [root@nik: /usr] traceroute anoncvs.freebsd.org traceroute to usw7.freebsd.org (209.181.243.20), 64 hops max, 40 byte packets 1 128.9.160.7 (128.9.160.7) 2.168 ms 2.403 ms 1.274 ms 2 128.9.0.9 (128.9.0.9) 2.613 ms 2.435 ms 3.095 ms 3 dmz-ln (198.32.16.50) 5.182 ms 1.890 ms 1.592 ms 4 ge-2-3-0.a02.lsanca02.us.ra.verio.net (198.172.117.161) 1.811 ms 1.936 ms 4.248 ms 5 ge-6-2-0.r00.lsanca01.us.bb.verio.net (129.250.29.126) 1.584 ms 1.501 ms 2.023 ms 6 p4-0.att.lsanca01.us.bb.verio.net (129.250.9.186) 1.775 ms 2.754 ms 2.890 ms 7 gbr3-p50.la2ca.ip.att.net (12.123.28.130) 2.564 ms 1.750 ms 2.770 ms 8 gbr4-p20.sffca.ip.att.net (12.122.2.69) 19.755 ms 47.439 ms 18.800 ms 9 gbr3-p50.st6wa.ip.att.net (12.122.2.62) 26.823 ms 25.483 ms 25.285 ms 10 gbr1-p100.st6wa.ip.att.net (12.122.5.158) 26.408 ms 25.352 ms 25.295 ms 11 gar2-p360.st6wa.ip.att.net (12.123.44.113) 25.599 ms 25.391 ms 25.220 ms 12 12.124.173.62 (12.124.173.62) 41.901 ms 41.563 ms 41.912 ms 13 min-core-02.tamerica.net (205.171.8.114) 67.260 ms 66.793 ms 66.519 ms 14 gig12-0-0.mpls-cust2.mpls.uswest.net (207.225.159.252) 65.922 ms 66.060 ms 66.406 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 *^C Is anyone else seeing this? Lots of messages on cvs-all seem to indicate the box is up, and it's a routing issue. Is there a mirror somewhere? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: anoncvs.freebsd.org reachability
Wilko Bulte wrote: On Mon, Feb 10, 2003 at 11:53:25AM -0800, Lars Eggert wrote: As I understand it there are issues at USW which are being investigated. Great, thanks! In the meantime, is there an easy way to switch over my existing CVS tree to a mirror? (And is there a mirror?) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: 5400RPM|7200RPM Cable bottleneck?
On 1/18/2003 2:50 AM, Scott Mitchell wrote: On Fri, Jan 17, 2003 at 06:18:38PM -0600, Jay Sern Liew wrote: Does anyone know if a NFS server with a 7200RPM IDE HD will perform significantly better than a 5400RPM IDE HD over a cable connection? I'm assuming that the performance will only be noticable iff the NFS client is close(geographically) to the NFS server, i.e. same LAN since the bottleneck would be at the network level. If by 'cable' you mean a cable modem providing at best a few Mb/s bandwidth, then I doubt the speed of your disk will have any impact whatsoever. Even the crappiest ATA disk will be able to deliver a few MB/s -- in the worst case that's still an order of magnitude more than you can stuff down your cable modem. I've tried NFS mounting ISI servers at home over PPTP over a cable modem connection, and it's painfully slow - much slower than the bandwidth of the cable pipe. NFS isn't well tuned for high-RTT environments (in my case, 20ms). If you get anything reasonable working, I'd be very interested in seeing your NFS parameters. Or, if you settle on anything else (AFS, etc.), I'd be interested to hear how that compares. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: 5400RPM|7200RPM Cable bottleneck?
On 1/18/2003 2:27 PM, Terry Lambert wrote: Lars Eggert wrote: I've tried NFS mounting ISI servers at home over PPTP over a cable modem connection, and it's painfully slow - much slower than the bandwidth of the cable pipe. NFS isn't well tuned for high-RTT environments (in my case, 20ms). The up-channel speed on a cable modem is usually in the neighborhood of 1.5 times the amount of bandwidth needed for just the ACKs for the data coming down the down-channel; that leaves very little bandwidth left over for NFS requests to the server, particularly if there are a lot of data transfers taking place from the server to the client (client reads). If you are doing any level of data transfers from the client to the server (client writes), you should expect your performance to go to hell. Both uplink and downlink bandwidths are nowhere near saturation - it's the underlying RPC that make NFS inherently slow over WAN links. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Automount from a Solaris NIS/NFS server?
Tiarnan O'Corrain wrote: I'm running FreeBSD 4.7-STABLE and have managed (after some difficulty), to get it to bind to a Solaris NIS server we have here. All NIS users can log on now, but I can't figure out how to get home directories automounted when users do log in. I tried a couple of things on the web, an awk script to transform the Solaris auto.home, to amd syntax, and it seems to work fine, except that no home directories are mounted when NIS users log in. We use the script approach at ISI (http://www.isi.edu/larse/etc/rc.d/isiconfig), and it works fine. Hoperfully the script will give you some ideas that'll apply to your configuration. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [ GEOM tests ] vinum drives lost
Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [ GEOM tests ] vinum drives lost
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Thanks for clearing that up! Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [ GEOM tests ] vinum drives lost
Lars Eggert wrote: Poul-Henning Kamp wrote: Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. I just replaced vinum with ccd on one machine, and it works fine with geom enabled, FYI. Performance between the two is also comparable. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: VPN Routing through gif (4) tunnel
Hi, Ian Cartwright wrote: I am trying to construct a B2B mode VPN tunnel between my house and my work using FreeBSD. ... Here is my current configuration (IPs changed to protect the guilty): fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 100.100.100.1 netmask 0xff00 broadcast 68.3.250.255 ... fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 ... gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 tunnel inet 68.3.250.5 -- 199.64.13.20 inet 192.168.0.1 -- 200.200.200.1 netmask 0xff00 fxp0 is my external network adapter, connected to the Internet and assigned 100.100.100.1 by my ISP. gif0 is the tunnel adapter and ties my network to my work's network. The ip 200.200.200.1 is the inside interface of my work's VPN server. The commands used to create the gif tunnel are as follows: ifconfig gif0 create tunnel 100.100.100.1 200.200.201.1 ifconfig gif0 inet 192.168.0.1 200.200.200.1 netmask 255.255.255.0 100.100.100.1 is my external address again 200.200.201.1 is the external interface on my work's VPN server 200.200.200.1 is the internal interface on my works VPN server again your tunnel configuration is a bit strange. You want the tunnel wrapper IP addresses to be those of the external interfaces, both locally and for your remote site. Also, give the tunnel itself addresses that don't overlap with addresses you already use. E.g.: ifconfig gif0 10.0.0.1 10.0.0.2 tunnel 100.100.100.1 external-ip-of-remote-end Then just add a route for your remote network to the tunnel, e.g. route add 200.200.200/24 10.0.0.2 As for IPsec and racoon: Are you negotiating IPsec tunnel mode SAs? In which case you MUST NOT set up a gif tunnel. (In short, that abuses the fact that two parallel tunnels trick routing into forwarding over a tunnel mode SA, with consequences; see ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-04.txt. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: VPN Routing through gif (4) tunnel
Ian, this stuff is definitly tricky to get into... :-) Ian Cartwright wrote: Thank you very much for the document, it was very informative. So what you are sayng is that I am running two tunnels in parallel? I had suspected this, but since it was the only way I was able to make it work and all the examples I could find fro FreeBSD involved a gif tunnel, I thought therer might be some special inbteraction with the kernel that required a gif tunnel for tunnel mode IPSec. I sent email to a bunch of tutorial authors that do the two-tunnel-in-parallel-thing when this came up on the list before. Two at least said they were going to modify their tutorials (when I wrote this I was still learning about this stuff, etc.), but I don't think they did yet. So, continuing with my configuration from my original message setkey -DP would shouw: 200.200.200.0/16[any] 192.168.0.0/24[any] any in ipsec esp/tunnel/200.200.201.1-100.100.100.1/require spid=8 seq=1 pid=8125 refcnt=1 192.168.0.0/24[any] 200.200.200.0/16[any] any out ipsec esp/tunnel/100.100.100.1-200.200.201.1/require spid=7 seq=0 pid=8125 refcnt=1 This has the same issues as your gif tunnel setup. You want the tunnel headers (i.e. what gets slapped onto as the outer header of your packets after IPsec processing) to go between your local gatway's external IP address (100.100.100.1) and the external interface of the VPN-1 box at the remote location (don't think that IP address was in your earlier email.) The selector (i.e. the pattern that decides which packets should go into the tunnel) would NORMALLY match the local and remote subnetworks. HOWEVER, since you're doing NAT, this is getting very tricky. One option is to select on the RFC1918 private addresses on both sides, i.e. grab the packets and IPsec-process them BEFORE they get NAT'ed. I'm pretty sure this could be made to work if both sides were using FreeBSD, but I'm not a fan of VPN-1 (see below). Another possibility would be to select the packets after they have been NAT'ed, but then negotioate a TRANSPORT mode SA. (Since NATs look like hosts to the network, transport mode betweenm them is valid.) Lars [The reason I'm sceptical about VPN-1 is that Checkpoint was using a range of ports that were registered to others - some to us - for their VPN-1 thing. When we contacted them about it, they seemed clueless about IANA and registered ports. Not the most confidence-inspiring behavior for a firewall vendor.] -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: VPN Routing through gif (4) tunnel
Ian, Ian Cartwright wrote: As I understand it, so long as the local tunnel endpoint is the external interface of the local gateway, the encapsulated traffic should already look like it is coming from the external interface and should not be NATed (while the traffic inside the tunnel looks like it is coming from my local RFC1918 network). Yes, the tunnel should go between the external addresses. But your NAT is still causing a problem. Consider this packet, send from a host on your local network to a host behind the remote tunnel end: | 192.168.0.10-200.200.200.20 | Data | When it reaches your local security gateway, there are two choices: (1) NAT gets the packet first, in which case it will be translated into | 100.100.100.1-200.200.200.20 | Data | (2) IPsec gets the packet first, in which case it will be encapsulated (## is the IPsec header): | 100.100.100.1-200.200.201.1 ## 192.168.0.10-200.200.200.20 | Data | If the second case occurs, your current SA should already cause this to happen. It is also my understanding that IPFILTER sees the traffic before the rest of the kernel (i.e. KAME) and may do the NATing before it enters the IPSec tunnel, thus munging the works entirely. This does not bode well. That is your problem, I think. IPfilter goes first, and your current SA does not match the NAT'ed packet. Try changing your SA so that the selector matches the packet under (1) above, so the final packet would look like | 100.100.100.1-200.200.201.1 ## 100.100.100.1-200.200.200.20 | Data | This is moderately ugly, since we're using the same address in the inner and outer header, but that's what you get for using NATs... Note that there's a good chance that the IPsec implementation on either side will balk at this. Was my original assumption correct, that as long as the tunnel is specified correctly in the SPD, that the routing will happen automgically? Yes. Once the correct SA is in place, forwarding over the tunnel should happen. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: top shows all zeroes.
Patrick Thomas wrote: 2. What is to be done ? I have no reason to believe this won't crop up on 4.6.2 or later...does anyone else ? I just saw it happen on today's -CURRENT on the same laptop (has ACPI). Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: top shows all zeroes.
Lars Eggert wrote: I just saw it happen on today's -CURRENT on the same laptop (has ACPI). And hit send too soon, there's another datapoint. When it happens on -CURRENT, the rtc at irq8 is happily ticking along. Also, unlike the subject, top does not show all zeroes: the interrupt and idle percentages are non-zero (but user, nice and system, and all per-process WCPU percentages are zeroes.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
Matthew Jacob wrote: That's damned odd. Can you get into the configuration menu and make sure it has 'large BIOS' or whatever the LSI term is enabled? The Dell BIOS, or the LSI config menu? I don't think either has a LSI Config - ^C. OK, I'm in the LSI config screen, and here's what I have in the first screen: LSI Logic MPT SCSI Setup UtilityVersion MPTBIOS-5.02.00 Boot Adapter List Global Properties LSI Logic Host Bus Adapters Adapter PCI Dev/PortIRQ NVM BootLSI Logic Bus FuncNumber Order Control LSI1030 3 60 DC0011 Yes 1 Disabled LSI1030 3 61 D80011 Yes 0 Enabled I disabled one of them, since the drives hang off the other one and this shaves a few seconds off reboot times. Under Boot Adapter List, the only things I can change are the boot order and the status (enabled/disabled) of the two adaptors. Under Global Properties, I have: Pause When Boot Alert Displayed [No] Boot Information Display Mode [Verbose] Negotiate with devies [Supported] Video Mode [Color] Support Interrupt [Hook interrupt, the Default] Under the enabled device LSI1030 3 61, I have: Adapter Properties Adapter PCI Dev/ Bus Func LSI1030 3 61 Device Properties Host SCSI ID[ 7] SCSI Bus Scan Order [Low to High (0..Max)] Removable Media Support [None] CHS Mapping [SCSI Plug and Play Mapping] Spinup Delay (Secs) [ 2] Secondary Cluster Server[No] Termination Control [Auto] Under Device Properties, it shows some details about the connected drives and let me force them to a lower speed, etc. The only thing that comes close to large BIOS would be the CHS Mapping, but either setting (SCSI Plug and Play Mapping or Alternate CHS Mapping) doesn't boot. Or am I looking at the wrong thing? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
Matthew Jacob wrote: I was thinking that the CHS mapping had changed from your original settings when you loaded new f/w. Good and bad news: Good: Found the boot problem. Turns out that I moved BIOS boot devices before the SCSI drives in the BIOS, to boot of the LSI firmware floppy. That made an ATA drive the first drive to be probed. Even though I cycled through the boot loader chain to the right (SCSI) disk, it then wouldn't boot. I moved the SCSI drives before the BIOS devices again, and now it boots fine. (Still strange, since all drives have the 4.6 boot loader installed, but anyway, it boots again.) Bad: I still get timeouts with the 1.00.12 firmware. And, unlike before, my drives only attach at 80MB/s - and this is with the patch to scsi_all.c that I initially forgot yesterday. At boot time, the 1.00.12 firmware detects my drives as 80MB/s but posts a note along the lines of these drives will support 320MB/s once the OS is loaded. The older version detected them as 320MB/s at boot, and so did FreeBSD. Windows XP with the 1.00.12 firmware, on the other hand, runs the drives at 320MB/s (according to the LSI utility). 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 ... da0 at mpt1 bus 0 target 0 lun 0 da0: SEAGATE ST336732LW 2223 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.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: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
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? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
Matthew, Matthew Jacob wrote: This isn't good. Part of it just the chip later presenting the completion for a command that I had already timed out. But basically, we never got a response to a command, so we timed it out. Later, the chip presented us with the comamnd as being done- and being done with no errors (hence the 'context reply'). Can you say if there was a perceptible period of time between the first and second barfings? there is a longish (30 seconds?) pause before the first message, then I get them all in one swoop. E.g. I type make buildworld, make seems to hang, and then I get these messages 30 seconds later. Oh, yes- let me know if you've upgraded to the latest LSI 53c1030 f/w (that'd 1.0.12). No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI and installed it, but now none of my partitions likes to boot anymore (FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all drives as Ultra-320, now it shows them as Ultra-80 with a note saying should support Ultra-320 when the OS is loaded. Is this to be expected, i.e. do I need to reinstall everything with the new firmware? I'm trying to find the original Dell-branded firmware somewhere, but so far, no luck. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
Matthew Jacob wrote: In some sense this sounds like an interrupt issue. The timeout is 30 seconds, and it looks like we give up on the command but it's done instantaneously afterwards. Hm. I don't know much about the PCI code, so maybe what follows won't make any sense and may not be related: The card is PCI64, and there's an unknown device in the dmesg that is an Intel 82806AA I/O APIC Device according to its device ID. Would that matter at all? No, I was running a Dell-branded 1.0.0. I grabbed the update from LSI and installed it, but now none of my partitions likes to boot anymore (FreeBSD and Windows XP). Also, the LSI firmware prompt used to show all drives as Ultra-320, now it shows them as Ultra-80 with a note saying should support Ultra-320 when the OS is loaded. Is this to be expected, i.e. do I need to reinstall everything with the new firmware? *sputter* That's damned odd. Can you get into the configuration menu and make sure it has 'large BIOS' or whatever the LSI term is enabled? The Dell BIOS, or the LSI config menu? I don't think either has a setting that sounds similar, but I'll double-check tomorrow. I'm trying to find the original Dell-branded firmware somewhere, but so far, no luck. *groan* I might have an image somewhere around... hang on... check my directory on hub- there's 1.0.6 there... That'd be great. I also emailed Dell and LSI. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
Peter Wemm wrote: Jonathan Lemon wrote: I have an IBM box that has a dual LSI 53c1030 controller on the motherboard. Our SYM driver doesn't appear to have support for this device; under Linux it is supported by a Fusion/MPT driver from LSI. Any chance of getting a driver for this chip? I have an IA64 box with a 1030 as well. :-/ We just got a bunch of Dell machines that have this controller as well. Any news about support in sym? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra320 drivers?
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 just saw the message on cvs-all :-) Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: SMP P4 Xeons out there?
Lars Eggert wrote: Doug White wrote: Anyone other there with multiprocessor P4 Xeon systems with Hyperthreading enabled that are seeing 4 CPUs show up on boot? Not yet, but we're expecting some Dell Precision 530s later this week - I'll let you know. Just got them, and no, 4.6-RELEASE only sees two CPUs with hyperthreading, not four. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: top shows all zeroes.
Patrick Thomas wrote: Now, when I repeat vmstat -i, all of these numbers (or rather, all of the large numbers) increase _except_ for `rtc irq8`. interrupt total rate mux irq114851 12 ata0 irq14 94219240 atkbd0 irq1 399 1 fdc0 irq6 2 0 ppc0 irq7 1 0 clk irq039123100 Total 138595354 Large ones increasing, too, but I don't seem to have rtc. Further, regarding the APM conjecture, this is a server and (although I may be mistaken) does not have APM in the bios at all - I have also removed it from the kernel. dmesg tends to confirm the absence of APM. Mine's a laptop with APM enabled (BIOS + kernel). Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: IP routing question
Julian Elischer wrote: On Tue, 13 Aug 2002, Les Biffle wrote: I want to do the following: 1. Create n IPSEC VPN tunnels 2. Create n VLAN pseudo interfaces 3. Route IP Packets based on their arrival iface/tunnel out through a corresponding tunnel/iface. For example, I want to route all packets received through VPN tunnel 2 out through VLAN 2, and all packets received on VLAN 2 out through VPN 2, without regard to source or destination IP Addresses. incoming packets should be selectabl in ipfw by using the clause in recv gif0 Minor point: IPsec tunnel mode tunnels aren't gif tunnels - he'd need to use IPIP tunnels + IPsec transport mode in that case (see draft-touch-ipsec-vpn04.txt), which I recommend anyway, of course :-) I hadn't thought of using the ipfw in selector, good idea! Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: IP routing question
Terry Lambert wrote: Les Biffle wrote: You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, but then you say you don't want to look at IP addresses... I'm happy to look at outside addresses, just not the ones on the inside. I would also consider matching up endpoint (VPN gateway or outside) address and SPI to know which SA a packet is arriving on, for the inbound-through-tunnel direction, and then use the vlan interface name to help select the departing tunnel, if possible. So no, I don't see how it can be done under your constraints. Well, not perhaps without some nethacks in the kernel. I've certainly done that before, but would prefer something more vanilla. One short answer is to not set a default route, per se. I know this is ugly, but it fixes the IPSec tunnel problem. I don't think we have the same definition of the IPSec tunnel problem. Mine is tunnel mode SAs aren't interfaces, and IPsec duplicates encapsulation and firewalling techniques that are (better) handled outside IPsec, see draft-touch-ipsec-vpn. Having or not having a default route won't matter, since you'll have more specific routes that match before the default route would be picked. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: SMP P4 Xeons out there?
Doug White wrote: Hey folks, Anyone other there with multiprocessor P4 Xeon systems with Hyperthreading enabled that are seeing 4 CPUs show up on boot? Not yet, but we're expecting some Dell Precision 530s later this week - I'll let you know. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
/usr/lib/libtelnet.a missing on 4.6?
[Originally posted to -net, but it looks like -hackers is a better place for it.] Hi, I'm trying to build the latest KAME SNAP, and the build fails, because /usr/lib/libtelnet.a is missing on a freshly installed 4.6-RELEASE system (installed from CD). None of our 4.6 systems has it, all of our 4.5 systems do. Is this a bug of the ISO image, or a deliberate change? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: gif(4) tunnel through MSN DSL modem
John Nielsen wrote: [excerpts from rc.conf on far (DSL) end] # Private interface ifconfig_xl0=inet 192.168.6.1 netmask 255.255.255.0 # Public interface -- 192.168.1.2 netmask 255.255.255.252 ifconfig_ed0=DHCP gif_interfaces=gif0 gifconfig_gif0=DSL.public.ip myend.public.ip ifconfig_gif0=192.168.6.1 192.168.0.1 static_routes=john route_john=-net 192.168.0 -interface gif0 The problem (one part, at least) is that you use the same IP address (192.168.6.1) on your xl0 and gif0 interfaces (on both ends). You'll want the tunnel addresses to be in a different subnet. Also, the netmask in the infconfig_xl0 line doesn't match the comment, which one is wrong? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: gif(4) tunnel through MSN DSL modem
John Nielsen wrote: # Public interface -- 192.168.1.2 netmask 255.255.255.252 ifconfig_ed0=DHCP gif_interfaces=gif0 gifconfig_gif0=DSL.public.ip myend.public.ip ifconfig_gif0=192.168.6.1 192.168.0.1 static_routes=john route_john=-net 192.168.0 -interface gif0 The problem (one part, at least) is that you use the same IP address (192.168.6.1) on your xl0 and gif0 interfaces (on both ends). You'll want the tunnel addresses to be in a different subnet. I have another tunnel set up this way and it works fine. Why should the tunnel addresses be on a different subnet? Because your routing table will have an entry that says to reach net X use gateway Y, and there will appear to be multiple ways to reach gateway Y if you have multiple addresses attached to the same subnet. Also, assigning the same IP address to multiple interfaces is usually a bad idea. (It is useful in some setups, but this ain't one.) Add encapsulation, and you've a fine example of black hole due to infinite encapsulation. Also, the netmask in the infconfig_xl0 line doesn't match the comment, which one is wrong? The public interface (ed0) always gets the same address from the DSL modem, even though it's using DHCP. I think you associated the comment with the wrong ifconfig line (I've added a break between them to clarify). Oh, you're right, sorry. But then you're assigning the same IP address to THREE interfaces! I'm starting to think that it would be easier to use ppp/tun and ssh rather than gif in this instance, even though I'm less familiar with that arrangement. I'm willing to bet a beer that these problems will dissappear if you pick different subnets and IP addresses for your interfaces. This is a pretty straightforward setup. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Dinesh Nair wrote: I see very common short-term hangs, a few seconds to less than a minute. The mouse and keyboard stop responding, X stops updating and everything just pauses, the whole system (including the network). It then starts i've seen this happen on an Asus 1400R 1U rackmount server, P3 1Ghz, dual intel etherexpress pro (fxp devices), 4GB RAM. thru trial and error i tracked it down to apm causing it. I can't disable apm in the BIOS (doesn't have an option for it) but it's not enabled in the kernel - we were getting spurious signal 11's with apm on SMP machines several years ago, and the mailing list consensus back then was apm is not for SMP. So either it's something else, or my BIOS is lacking an option. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Frank Mayhar wrote: I see very common short-term hangs, a few seconds to less than a minute. The mouse and keyboard stop responding, X stops updating and everything just pauses, the whole system (including the network). It then starts back up, often dropping keyboard or mouse data. Once in a while (not sure how often, but at least every couple of days) it hangs solid and never comes back. Totally unresponsive. This invariably requires a hard reset. This is a busy system. Near-constant load on the network (some 40-100KB/s), lots of disk accesses. Seems worse when network and/or SCSI load is high. I've seen these, too, on a dual-P3 Dell Precision 420. Under high loads (buildworld), I get the exact same short-time freezes that sometimes recover, and sometimes lockup the machine solid. We have the same sound card (and network card), and in my case, not playing audio during high loads solves the problem - are you using your audio device at all when this happens? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Frank Mayhar wrote: I've seen these, too, on a dual-P3 Dell Precision 420. Under high loads (buildworld), I get the exact same short-time freezes that sometimes recover, and sometimes lockup the machine solid. We have the same sound card (and network card), and in my case, not playing audio during high loads solves the problem - are you using your audio device at all when this happens? Nope. Well, sometimes, but not often. When I am, I get the repeating the last sample effect during the freeze, the same as if the sound card wasn't generating interrupts (or the system wasn't servicing those interrupts). This is one of the things that makes me suspect interrupt problems. I get the repeating last sample also (good way to describe it). This may be unrelated, but I also found out that the sound driver isn't happy when the card shares its IRQ with someone. The Dell Precision has an onboard SCSI controller that by default shares an IRQ with the sound card. Even with no SCSI disks connected, the sound would be really choppy. When I disabled the SCSI controller in the BIOS, those problems went away. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Project: a benchmark utility
John Baldwin wrote: Once I have that, it would be nice to have a simple tool that would take one of these tabular files as input and spit out appropriate statistics about each column (mean, mode, median, stddev, highlight outliers, etc.). If some sensible (i.e. meaningful) graphs can be generated from this data using gnuplot or some such that would be nice, too. Any takers? You want John Heidemann's JDB! I'm using it for any number crunching I need to do for my benchmarks. http://www.isi.edu/~johnh/SOFTWARE/JDB/index.html Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
get/setuid used instead of get/seteuid?
Hi, there's a large number of system programs that use get/setuid() to limit what a non-root user can do (route, killall, ping, etc.) This may be a really dumb question, but shouldn't they be using get/seteuid() instead, to base their decision on the effective uid? Otherwise setting the setuid flag on the binary has no effect. For example, setting the setuid flag on ping (so non-root users can use flood pings - I am aware of the security implications, this is for a prototype system that will never go live) does not work - ping checks the real uid instead. Or is this deliberate? If so, there's other system programs (e.g. reboot) that check the euid instead. (Or is the inconsistency deliberate?) Can someone shed some light on this? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: SMP kernel freezes with nice processes.
David Gilbert wrote: I run dnetc with an argument to run two (one for each processor). If I realtime nice (not nasty) the processes, the computer freezes for a few seconds every minute or two. If I have them only regular nice'd, this does not happen. realtime nice = idprio? If so, probably priority inversion. Not much you can do about that without looking at the dnetc source any finding out which resources it holds locked. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Anyone using pptp?
Thomas David Rivers wrote: Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? This is a FAQ on -net. There's been a couple of threads on this recently, and configuration examples were posted for mpd. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: USB Memorybird quirks
There is some (maybe) related code that has been sitting for a while in PR misc/32490 (http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/32490) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: perfomance and regular expressions
Ilia Chipitsine wrote:
I'm currently implementing a program which will run thousands and
thousands times. It uses regular expressions.
something really simple, like
regex_t re;
regcomp(re,^[0123456789abcdefghijklmnopqrstuvwxyz]{1,8}$,
REG_EXTENDED+REG_ICASE);
return(!regexec(re,name,0,0,0));
so, questions are:
1) is it faster to compile regex once and load it from file every time
program starts ?
2) how to store in a file data of type regex_t ??
Try using flex.
Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
Re: usb mass storage problems
Thomas Würfl wrote:
I fixed the problem. I added following lines to
/usr/src/sys/cam/scsi/scsi_da.c (FreeBSD-4.5RELEASE):
/* Below a list of quirks for USB devices supported by umass. */
/*
+ * Fujitsu Siemens Memorybird
+ */
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Fujitsu, Memorybird, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
+ },
Maybe this is written in an unusual manner, but I'm an absolute newbie to
freebsd and C. Sorry
For reference, there's a more generalized approach to supporting these
devices that's been sitting in PR misc/32490
(http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/32490) for a while :-)Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
Re: idprio
Andrew wrote: Under FreeBSD system calls are currently never preempted, therefore non- realtime processes can starve realtime processes, or idletime processes can starve normal priority processes. Even so an idprio process can't be worse than a normal process. Practically this means you will still see a drop in your foreground performance. Theoretically, however, you can construct scenarios where your foreground stuff is starved ad infinitum due to priority inversion. (Since some/most non-CPU resources don't support priorities and preemption.) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
Zhihui Zhang wrote:
Well, the core of my program is as follows (RANDOM(x) return a value
between 0 and x):
blocksize = 8192;
write_size_low = 512;
time(time1);
for (i = 0; i write_count; i++) {
write_size = write_size_low +
RANDOM(write_size_high-write_size_low);
write_size = roundup(write_size, DEV_BSIZE);
if (testcase == 1)
write_size = blocksize;
write_block(rawfd, sectorno, buf, write_size);
sectorno += blocksize / DEV_BSIZE;
}
time(time2);
If testcase is one, then the time elapsed (time2 - time1) is much less.
How much less in milliseconds?
Also, in your original mail, you said you had 15,000 of these 8K blocks,
which is only 120MB or so. Use 150,000 or 1,500,000 and check your
results then.
Lars
-Zhihui
On Tue, 5 Mar 2002, Lars Eggert wrote:
I agree that it's probably caching at some level. You're only writing
about 120MB of data (and half that in your second case). Bump these to a
couple of GB and see what happens.
Also, could you post your actual measurements?
Lars
Zhihui Zhang wrote:
The machine has 128M memory. I am doing physical I/O one block at a time,
so there should be no memory copy.
-Zhihui
On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote:
At 16:03 5-3-2002 -0500, Zhihui Zhang wrote:
On Tue, 5 Mar 2002, Julian Elischer wrote:
more writes fit in the disk's write cache?
For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 *
4096 bytes in all (assuming the random number distributes evenly between 0
and 8192). So your suggestion does not make sense to me.
How large is your buffercache? it might be that the 15000 * ~4096 roughly
matches with your cache, and 15000 * 8912 doesn't.
Case (1) would require a lot more physical IO in that case than case (2)
would require.
Doc
-Zhihui
On Tue, 5 Mar 2002, Zhihui Zhang wrote:
I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5.
This situation is like this:
+-++++++++++---+--
| |||||||||| |
+-++++++++++---+--
Each block is of fixed size, say 8192 bytes. Now I have a user program
writing each contiguously laid out block sequentially using /dev/daxxx
interface. There are a lot of them, say 15000. I write the blocks in two
ways (the data used in writing are garbage):
(1) Write each block fully and sequentially, ie. 8192 bytes.
(2) I still write these blocks sequentially, but for each block I only
write part of it. Exactly how many bytes are written inside each
block is
determinted by a random number between 512 .. 8192 bytes (rounded up a
to multiple of 512 bytes).
I find out the the performance of (2) is several times better than the
performance of (1). Can anyone explain to me why this is the case?
Thanks for any suggestions or hints.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
Zhihui Zhang wrote:
Several times slower! The point is that writing less data performs
worse. So I call it weird.
Huh? You originally said:
(1) Write each block fully and sequentially, ie. 8192 bytes.
(2) I still write these blocks sequentially, but for each block I only
write part of it.
...
I find out the the performance of (2) is several times better than the
performance of (1). Can anyone explain to me why this is the case?
If (2) is better than (1), then writing *less* data is faster. Which is
it, now?
Lars
-Zhihui
On Tue, 5 Mar 2002, Lars Eggert wrote:
Zhihui Zhang wrote:
Well, the core of my program is as follows (RANDOM(x) return a value
between 0 and x):
blocksize = 8192;
write_size_low = 512;
time(time1);
for (i = 0; i write_count; i++) {
write_size = write_size_low +
RANDOM(write_size_high-write_size_low);
write_size = roundup(write_size, DEV_BSIZE);
if (testcase == 1)
write_size = blocksize;
write_block(rawfd, sectorno, buf, write_size);
sectorno += blocksize / DEV_BSIZE;
}
time(time2);
If testcase is one, then the time elapsed (time2 - time1) is much less.
How much less in milliseconds?
Also, in your original mail, you said you had 15,000 of these 8K blocks,
which is only 120MB or so. Use 150,000 or 1,500,000 and check your
results then.
Lars
-Zhihui
On Tue, 5 Mar 2002, Lars Eggert wrote:
I agree that it's probably caching at some level. You're only writing
about 120MB of data (and half that in your second case). Bump these to a
couple of GB and see what happens.
Also, could you post your actual measurements?
Lars
Zhihui Zhang wrote:
The machine has 128M memory. I am doing physical I/O one block at a time,
so there should be no memory copy.
-Zhihui
On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote:
At 16:03 5-3-2002 -0500, Zhihui Zhang wrote:
On Tue, 5 Mar 2002, Julian Elischer wrote:
more writes fit in the disk's write cache?
For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 *
4096 bytes in all (assuming the random number distributes evenly between 0
and 8192). So your suggestion does not make sense to me.
How large is your buffercache? it might be that the 15000 * ~4096 roughly
matches with your cache, and 15000 * 8912 doesn't.
Case (1) would require a lot more physical IO in that case than case (2)
would require.
Doc
-Zhihui
On Tue, 5 Mar 2002, Zhihui Zhang wrote:
I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5.
This situation is like this:
+-++++++++++---+--
| |||||||||| |
+-++++++++++---+--
Each block is of fixed size, say 8192 bytes. Now I have a user program
writing each contiguously laid out block sequentially using /dev/daxxx
interface. There are a lot of them, say 15000. I write the blocks in two
ways (the data used in writing are garbage):
(1) Write each block fully and sequentially, ie. 8192 bytes.
(2) I still write these blocks sequentially, but for each block I only
write part of it. Exactly how many bytes are written inside each
block is
determinted by a random number between 512 .. 8192 bytes (rounded up a
to multiple of 512 bytes).
I find out the the performance of (2) is several times better than the
performance of (1). Can anyone explain to me why this is the case?
Thanks for any suggestions or hints.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
which irqs are generally good for rndcontrol?
Hi, quick question: Are there any irqs that are generally a good source of entropy, for use with rndcontrol? I need a single setting that works well on a number of different machines (for our default configuration). Are there any drawbacks to specifying many irqs here (in the hope that some have good entropy on some machines, and others on other)? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: which irqs are generally good for rndcontrol?
Dominic Marks wrote: quick question: Are there any irqs that are generally a good source of entropy, for use with rndcontrol? I need a single setting that works well on a number of different machines (for our default configuration). Are there any drawbacks to specifying many irqs here (in the hope that some have good entropy on some machines, and others on other)? I think this was debated before, and I seem to remember Mike Silbersack was the original poster. You might like to search the archives and see. Or my memory could be in a twist (?). All I found in the archives was a related discussion if using CPU temperature and fan speed would be good sources of entropy. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
priority disk scheduling?
Hi, does anyone know if a simple priority disk scheduler exists for a recent (4.X) FreeBSD? I don't need anything fancy, basically the POSIX rtprio equivalent for disks. The Eclipse people (at Bell) have something like that, but it's based on an older kernel, and I'd rather use something more recent before looking into porting their stuff. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: cpu info in userland
Brooks Davis wrote: I'm trying to figure out how to get it from userland (in a shell script). I've looked at the cpuid port which seems to do most of it, but it doesn't display clock speed, only works on IA32 cpus, and won't be accurate if we have mismatched CPUs.[0] FWIW, there's a bad hack in i386/27627 (http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/27627) that puts the CPU speed at startup into a sysctl. It's been shot down in -hackers a while ago for various (totally justified) reasons, but it does the job for me locally. :-) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: userland program panics freebsd 4.3
Kris Kennaway wrote: OK, so what you're saying is that you haven't even tried to report the problem such that it can be fixed. I don't think it's fair to hold your lack of communication about your problem against the FreeBSD sound developers; if you want this to get fixed then you really need to get the ball rolling yourself by doing the best you can to describe and detail the problem in a PR. If you're missing details then someone will ask for them. Exactly! I have had extremely good experiences with PRs in general, and things are getting better still. Kudos all around. Even if you can't provide enough information in the initial PR, the person looking at it will usually tell you what other information is needed to debug things, and how to obtain it. Hoping that someone else will submit a PR for your problem is not very efficient. It is true, however, that a PR may fall through the cracks sometimes. It isn't a bad idea to ping a newsgroup about a PR after some reasonable time after submission (a week or two). Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cable modem connection problem
S. Aeschbacher wrote: Hal Snyder wrote: [snip] Sounds as if the MAC of the upstream provider occasionally changes. Don't know enough about cable to understand it better, and problem is gone now so can't check for sure. As far as my cases are concerned, the MAC address does not change. When the arp entry is deleted, the same MAC of the gateway is inserted into the arp table. Actually, it sounds like your provider actively mucks with the link after a certain time - are these residential pipes? If so, they may do that to prevent you from running servers. In any case, I'd be surprised if this really was a FreeBSD issue; I really think it's the provider doing something weird. (And on Windows you'll never see the problem, since you typically reboot more frequently than every 10 hours anyway... :-) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cable modem connection problem
S. Aeschbacher wrote: This is possible, but I did not verify it (what kind of mucking could cause such kind of behaviour?). most of them are better residental pipes. Having a packet filter drop your traffic after you haven't done ARP/DHCP in a while. But I agree that's pretty far-fetched. Never said it was a FreeBSD issue, I saw OpenBSD behave exactly the same. Ah sorry, missed that in earlier mails. The problem seems to occur only on Samsung modems. Ah! Another data point. Then I'd assume it's the modem. Have you tried powercycling it? (That should keep the ARP cache on the client intact). Tried to email Samsung? Is there a firmware update? Cannot confirm this as i don't use windows. I heard of a friend of mine, that he has running a windows ftp-server for days on a pipe from the same provider with another modem (a Com21) and that he is not experiencing any of the problems mentioned. Can he/she tcpdump for ARP packets? Maybe Windows' ARP cache timeout is lower than FreeBSD's. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Nat through two DSL
Anders Hagman wrote: I want to load share between two ADSL modems using a NAT/Firewall. Computer 1 \ \ /-- ADSL 1 \ / Computer 2 -- Wireless LAN --- Firewall/NAT - ./ \ . / \-- ADSL 2 Computer 10/ The ADSL are 500k links and I want to load share on session by session. Can I do NAT between an inside interface and two outside interfaces acting in a round robin fashion? This may not be the good idea you'd think on first glance. If one of the paths has a slightly different RTT (and they're pretty much guaranteed to), you'll see out-of-order delivery at the receiver. I remember seeing some study that showed that TCP doesn't react too nicely under such conditions (it works, but not at peak performance). Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Nat through two DSL
Steve Ames wrote: I want to load share between two ADSL modems using a NAT/Firewall. ... The ADSL are 500k links and I want to load share on session by session. Can I do NAT between an inside interface and two outside interfaces acting in a round robin fashion? This may not be the good idea you'd think on first glance. If one of the paths has a slightly different RTT (and they're pretty much guaranteed to), you'll see out-of-order delivery at the receiver. I remember seeing some study that showed that TCP doesn't react too nicely under such conditions (it works, but not at peak performance). Is it even possible to do use two upstream paths for redundancy? I tried (very briefly while I had two broadband connections while switching from one to the other) to get that to work and wasn't very successful. Redundancy is a different issue from load-sharing. If you want to switch between a primary and a backup link there are a number of ways to do this. However, Anders was trying to stripe packets over both links (not technically a problem) to increase throughtput. When running TCP over a striped link, you may not see the performance gain you'd expect. (I wish I could remember which paper I saw this in. Anyone know?) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Nat through two DSL
rick norman wrote: What would be nice would be to load balance on a per connection basis, not a per packet basis, between the two modems. Any ideas how to do this ? Not with the current mechanisms in FreeBSD. You'd need a simple policy routing engine (actually, policy forwarding). A prototype based on tun devices shouldn't be too hard to put together. Basically, you'd want to pick one of your links based on destination address and optionally the port pair. We're putting something similar together for the DynaBone project (http://www.isi.edu/dynabone/), but it just got underway. Anders Hagman wrote: The ADSL are 500k links and I want to load share on session by session. Ah, just caught the session by session part on second reading. In this case, my prior comment about packet-level striping and TCP is moot. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Nat through two DSL
Nick Rogness wrote: Load sharing is not possible on a per packet basis when running NAT on the outside interfaces. The source address for each packet will be different. What prevents you from picking one source address for packets going out both interfaces? Your return packets won't be striped then of course. (Which could make this scheme ineffective, assuming client machines receive much more than they send.) (Aside: Whether or not NAT is present is orthogonal to striping, just assume the NAT box is the source/sink for all traffic.) On a per session basis, you may be able to work with ipfw fwd (which does policy based forwarding) and the ipfw probability work done by Luigi. man ipfw for more info. I didn't know about that, thanks for the pointer! I use ipfw strictly as a firewall :-) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Nat through two DSL
Nick Rogness wrote: On Fri, 7 Dec 2001, Lars Eggert wrote: What prevents you from picking one source address for packets going out both interfaces? Your return packets won't be striped then of course. (Which could make this scheme ineffective, assuming client machines receive much more than they send.) Well, you can. But the upstream provider has to be allowing you to route the other ADSL's IP through their networkprobably not going to happen...unless you have some sort of BGP arrangement with them. If you have BGP arrangements with them this would be a moot point. Good point. I keep assuming that the Internet is a nicer place than it really is. But source-based filtering sounds like one of the things providers would do. You could set up IP tunnels to get around this, but this assumes the peer understands this, which makes it useless in the general case. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Success! [with patch] (was Re: umass ATAPI)
Martin Heller wrote: I can confirm that the patches are also working flawlessly for a Pentax Optio 330 on a 5.0-current system. Great! Did you try the patch I posted (quirks added to scsi_da.c) or the one from the PR? (They're different.) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Problem with two smbus devices
Hi, we have a couple of 4.4-RELEASE machines that have both Intel 82801AA (ICH) SMBus controllers and BrookTree 878 TV cards. Both of these attach to smbus devices, the BrookTree to smbus0 and the Intel to smbus1. The problem is that all system status utilities I tried (wmhm, wmlmmon, etc.) access smbus0, which is the TV card, causing a kernel hang. Is there any way to force the Intel controller to attach to smbus0 instead? (I could patch the source of the utilities, but they need to be able to run on standard machines as well.) Here's the relevant dmesg output: bktr0: BrookTree 878 mem 0xf6001000-0xf6001fff irq 13 at device 9.0 on pci2 iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: Hauppauge Model 61381 D423 bktr0: Detected a MSP3430G-A4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, msp3400c stereo, remote control. ichsmb0: Intel 82801AA (ICH) SMBus controller port 0xdcd0-0xdcdf irq 13 at device 31.3 on pci0 smbus1: System Management Bus on ichsmb0 smb1: SMBus general purpose I/O on smbus1 Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cable modem connection problem
S. Aeschbacher wrote: A solution I found is deleting the arp table entry of the default router of the cable modem provider (as a cron job). I did not investigate the source of the problem. Anyone got any clues? This sounds a lot like your cable modem provider throtteling the link if it doesn't see some sort of negotiation (DHCP, ARP, etc.) after a fixed amount of time. I could imagine that some companies do this for residential connections. Does your cable modem provide IP service, or do you need PPPoE or something like that? Mike D wrote: I have a set up where my FreeBSD 4.4 box is acting as a firewall and gateway between a cable modem on xl1 and my home net on xl0. ... It seems that after approx 10 hours the connection REALLY slows down, most connection attempts on other ports (e.g. 110) time out and I have to reboot the box. After the reboot everything is back to normal. Is this going out from behind the box, or coming in from the Internet? Also, do you see packet drops or RTT increases (define slow). Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cable modem connection problem
Mike D wrote: going out. I haven't checked for either packet drops / RTT increase (how?) but when I say slow, I mean for eaxmple to get www.google.com up takes 5-10 minutes. Also other machines on the LAN can not really get out at all. If you ping/traceroute, do you see losses (and where)? If you look at netstat -s output, do you see retransmissions? Somebody mentioned on this list that deleting the arp table entry of the default router of the cable modem provider (as a cron job) solved the problem. Does this work for you, too? Could this have something to do with leases being renewed (by the isp dhcp server and consequently the cable modem) and FreeBSD not updating routing tables? (I'm guessing big time here - not an expert by any means) If your cable modem provides IP, it's probably not involved in the DHCP negotiations. Does your IP address change before you start to see this slowdown? Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
umass ATAPI
Hi, is anyone working on extending umass.c for ATAPI devices? My new digital camera identifies itself as an ATAPI device, but the corresponding code is commented out in umass.c, because it isn't complete and/or tested. (I'm running 4.4-RELEASE, but it doesn't look like -current is any different.) I've enabled the disabled code, and the camera probes and attaches correctly as da0. However, mounting it fails, because the ATAPI code in umass.c does not translate some commands that the mount tries to execute (cache sync, and some read_6 command - from memory, may be wrong). I'm kinda at loss on how to add the missing command translations (I poke around in the network stack normally), but I'd give it a shot if I had a little more background info on how to translate from ATAPI to SCSI. Any pointers? And I'd of course happily test whatever patches more qualified hackers come up with... :-) Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: umass ATAPI
Bernd Walter wrote: src/sys/cam/scsi/scsi_da.c has the quirk table for such things. There are also some cameras in there. Ian Dowse has suggested the same thing, I'll try the quirks. There's also a patch at http://groups.yahoo.com/group/usb-bsd/message/1233 that looks promising. A bunch of entries have been MFS'ed shortly so if you had named your device we would know better if it's already special handled. Ooops, sorry - it's a Pentax Optio 430. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Success! [with patch] (was Re: umass ATAPI)
Bernd Walter wrote: Are you shure you need to change the #if 0? Especialy the first should only have an effect on different devices. Can you please try with both to default and if that failed with the first on default. Sure! With both = 0, I get: umass0: Unsupported command protocol 5 ugen0: ASAHI PENTAX OPTIO 430, rev 1.00/10.00, addr 2 With the first = 0 and the second = 1, everything works as before, so I agree that the first block probably doesn't matter. (I simply enabled everything that said ATAPI when I made the change.) However: I found that I sometimes get kernel crashes when attaching the camera, after these messages (copied by hand, may have typos): umass0: ASAHI PENTAX PENTAX OPTIO 430, rev. 1.00/10.00, addr 2, 8070i (ATAPI) over CBI umass-sim:0:-1:-1:XPT_PATH_INQ:. umass0:0:0:-1: Attached to scbus0 as device 0 scbus0: scanning for umass0:0:0:-1 umass-sim:0:-1:-1:XPT_PATH_INQ:. umass0:0:0:0::XPT_PATH_INQ:. umass0:0:0:0::XPT_PATH_INQ:. umass0:0:0:0::XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass-sim:0:1:0:func_code 0x0004: Invalid target (no wildcard) umass0: Handling CBI state 10 (CBI Command), xfer=0xc3eb6800, NORMAL_COMPLETION These crashes happen only one the first attach (subsequent ones are fine *if* the first one succeeded), and not always on the first one. The strange thing is that they *only* seem to happen when I attach right after bootup *before* anyone logs in. After someone logs in, it never crashed (yet). It also doesn't crash if the camera was attached *during* boot. Any clues? (Can't produce a crashdump, kernel doesn't enter DDB when crashing). Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Success! [with patch] (was Re: umass ATAPI)
Hi, Bernd and me have mailed privately, and there's another solution besides adding a quirk to scsi_da.c. It's based on a patch posted by Gerd Knops to the usb-bsd list (http://groups.yahoo.com/group/usb-bsd/message/1233). It adds 6-to-10 conversion for SCSI commands, which makes many devices work that needed quirks before. I've verified that this (also) enables attaching, mounting and accessing a Pentax Optio 430 digital camera, which identifies itself as an ATAPI device. I've put the patch into a PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=32490) in case someone would like to clean it up and commit it. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: application/pkcs7-signature
NFS append race (was Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328)
[Should have included this in my earlier mail, sorry.]
In addition to bad cookies, I also see the following messages very
frequently:
NFS append race @0:954
They're issued in nfs/nfs_bio.c:
/*
* If dirtyend exceeds file size, chop it down. This should
* not normally occur but there is an append race where it
* might occur XXX, so we log it.
*
* If the chopping creates a reverse-indexed or degenerate
* situation with dirtyoff/end, we 0 both of them.
*/
if (bp-b_dirtyend bcount) {
printf(NFS append race @%lx:%d\n,
(long)bp-b_blkno * DEV_BSIZE,
bp-b_dirtyend - bcount);
bp-b_dirtyend = bcount;
}
Any idea what these are about?
Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328
Matthew Emmerton wrote: What OS is running on the NFS client and server? I see these too, with a FreeBSD-4.4 client and SunOS 5.5.1 servers. Seen them with FreeBSD-4.2 clients to the same servers as well. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Console speed
Daniel Lang wrote: What I did: set BOOT_COMCONSOLE_SPEED=38400 in /etc/make.conf set options CONSPEED=38400 in KERNEL compiled and installed kernel and new bootstrap (with disklabel). changed /etc/ttys to use std.38400 as argument to getty. Me, too. Same thing, just with 115200 instead of 38400, and on 4.2-RELEASE. -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California S/MIME Cryptographic Signature
Re: apache
Dan Phoenix wrote: httpd in free(): warning: recursive call. What FreeBSD/apache versions is this with? I've seen the same on FreeBSD-3.4 and an older apache build from ports. Haven't (yet) seen it under 4.2 and the latest apache from ports. -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: capturing an early kernel dump
Peter Wemm wrote: Lars Eggert wrote: I'm playing with the networking code; by that time, the disks should have been probed. Hmm.. driver or stack? If it is a driver, then why not just kldload it? Stack. If you do a boot -v, you should see something like: 'creating disk ad0' and/or 'wd0' on RELENG_4 boxes, that is after interrupts are enabled and the minidisk layer can get to the disk partition info. It is probably too late for network stack stuff by then though as the stacks are initialized earlier. See sys/kernel.h for the SYSINIT ordering. Have a look at kern/kern_shutdown.c, setdumpdev(). Note the call to devsw-d_psize() - that gets the number of blocks in the partition. If you boot to multi-user you might be able to get these magic values and hardwire the bootstrap to set these values and dumpdev. Ah, yes, I'll try that. However... there is a BIG difference between RELENG_4 and -current in this area right how. In RELENG_4, dev_t (and hence dumpdev) is a simple integer for the minor/major number. I'm using 4.2-RELEASE+KAME, actually, since I depend on recent KAME/ALTQ changes, which aren't in -STABLE or -CURRENT. (Side note: AFAIK KAME in RELENG_4/CURRENT is still a version from 7/2000, and ALTQ isn't merged... will that be updated anytime soon?) Seriously though, please thoroughly check out the KLD module option and see if you can get that to work somehow. Unfortunately not an option... -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
capturing an early kernel dump
[Repost from last week, no answer then.] How do I capture an early kernel dump (before rc executes and sets dumpdev)? The dump partition used to be an option in the kernel config file, but that seems to have changed in 3.X or 4.X. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: capturing an early kernel dump
Lars Eggert wrote: How do I capture an early kernel dump (before rc executes and sets dumpdev)? How early? We could dump if you were prepared to hardwire in the minor and major device numbers to get to the devsw[] vectors and manually set the offsets. Not that early :-) I'm playing with the networking code; by that time, the disks should have been probed. Is there an "easy way" to configure a dump device after the disks are up? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
capturing an early kernel dump
How do I capture an early kernel dump (before rc executes and sets dumpdev)? The dump partition used to be an option in the kernel config file, but that seems to have changed in 3.X or 4.X. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: Embarrassing CVS question.
John Baldwin wrote: On 29-Nov-00 Stephen Hocking wrote: Say I have a cvs tree all nicely unpacked et cetera. How do I find out what tags are available - I ask this becuase I want to check out a second source tree (for 4.2 stable) in addition to current. Go find a file that is on all the branches (/usr/src/Makefile is a good candiate for FreeBSD's /usr/src) and do a 'cvs log | more' on it. cvs status -v -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
curproc question
Quick question: During a system call inside the kernel, can I safely assume that curproc points to the process that issued the call? For example, will looking at curproc in ip_output() tell me which process is responsible for generating the packet? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: curproc question
Mike Smith wrote: During a system call inside the kernel, can I safely assume that curproc points to the process that issued the call? For example, will looking at curproc in ip_output() tell me which process is responsible for generating the packet? No. Too bad. In which cases wouldn't it point at the "correct" process? Maybe I could tolerate those. -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
implementing idle-time networking
Hi, as part of my thesis research, I'm implementing something similar to the POSIX idle-time CPU scheduler for other resource types, one being network I/O. The basic idea is to substitute two-level queues for the standard ones. I'm seeing some unexpected things (explained below), but let me first outline what I'm doing exactly: 1. I extend the ifnet structure to contain a second ifqueue, for idle-time traffic; and also declare a new flag for mbufs, to indicate whether network idle-time processing should be done or not. 2. In sosend(), I check if the sending process is running at a POSIX idle-time priority. If so, I set the idle-time flag in the mbuf. 3. In ether_output_frame(), I check if the idle-time flag is set on an mbuf, and if so, enqueue it in the interface's idle-time queue (default queue otherwise.) 4. In xl_start() (my onboard chip happens to use the xl driver), I first check the default queue for any mbufs ready to send. If there are none, I try the idle-time queue. If an mbuf could be dequeued from either queue, I continue with normal outbound processing (have mbuf be picked up by NIC). Unfortunately, this scheme does not work. Some first experiments have shown that idle-time network performance is practically identical to regular-priority. I measured it going from a slower (10Mb/s) to a faster (100Mb/s) host through a private switch, so the NIC should be the bottleneck (the processors are both 800Mhz PIII). The new code is in fact executed, I have traced it heavily. Closer inspection revealed that both the ifnet ifqueues as well as the driver transmission chain are always empty upon enqueue/dequeue. Thus, even though my fancy queuing code is executed, it has no effect, since there never are any queues. Can someone shed some light on if this is expected behavior? Wouldn't that mean that as packets are being generated by the socket layer, they are handed down through the kernel to the driver one-by-one, incurring at interrupt for each packet? Or am I missing the obvious? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
measuring bus utilization
Quick question: Is there a way to measure PCI bus utilization using the P6 performance monitoring capabilities? Specifically, is BUS_DRDY_CLOCKS/ticks a a meaningful figure? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
Matt Dillon wrote: : Since the only effect of a cache miss is less efficient use of : the cpu, and since the page zeroing only occurs when the cpu is idle, : I would not expect to see much improvement from attempts to refine : the page-zeroing operation (beyond the simple hysteresis that FreeBSD : uses now and perhaps being able to bypass the cache). : :The reason why I'm interested in Cort's results is that I'd like to extend :processing in the idle loop to other things (see my other mail). Cort :measured a performance decrease of foreground processing, due to polluted :caches after idle-time processing. We're discussing if disabling caches :during the idle loop may prevent that. I think what you are observing may not be cache-related at all, but may simply be the fact that zeroing a page takes a minimum amount of time during which another task will not be scheduled, verses that other task being scheduled instantly if all the idle loop were doing was checking for new tasks to run. The way Cort implemented it in Linux was so that there's a check for new processes in the loop that clears a page. This is of course slowing it, but since it's idle time processing, reduction of latency to start a new process (and being transparent to foreground processing in general) is much more important than optimized execution. This is also why turning off L1 and L2 caches may be interesting - if one process blocks, you do some idle time processing and it unblocks, the L1 and L2 cache may be polluted by the idle time processing, slowing things down for the foreground process. Another alternative is to have an idle process rather then try to do things in the idle loop. This has the advantage of being instantly interruptable if a 'real' process becomes runnable, but the disadvantage of having to do a context switch (albeit a relatively cheap one). That would probably be the cleanest solution. Maybe the idprio mechanism could be extended to cover this. -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
(Cort, the reason I'm CCing you is that I'm interested in using some of the mechanism described in your OSDI'99 paper for FreeBSD, and I've some questions about your Linux implementation, see below.) Alan Cox wrote: Last year, I tried to reproduce some of the claims/results in this paper on FreeBSD/x86 and couldn't. I also tried limiting the idle loop to clearing pages of one particular color at a time. That way, the cache lines replaced by the second page you clear are the cache lines holding the first page you cleared, and so on for the third, fourth, ... pages cleared. Again, I saw no measurable effect on tests like "buildworld", which is a similar workload to the paper's if I recall correctly. Do you still have those FreeBSD patches, Alan? I'd be interested in doing some more experiments with that code. Finally, it's possible that having these pre-zeroed pages in your L2 cache might be beneficial if they get allocated and used right away. FreeBSD's idle loop zeroes the pages that are next in line for allocation. That makes sense. Other factors that may have an impact: * if you always have enough zeroed pages remaining over your benchmark ( ~1/2 free pages), FreeBSD will never do the idle-time zeroing * it looks to me as if Cort's Linux code will always zero whole pages, while the FreeBSD code is a little smarter and only zeroes used regions of a page (less impact on caches?) * cache size differences between PPC and i386? I'm looking at Cort's code (arch/ppc/kernel/idle.c), and while he turns off the caching for pages he zeroes, I don't see him disabling the L1/2 caches explicitly. Is this implicit with setting the non-cacheable flag on the PPC? Also, idle-time zeroing is commented out in the version I'm looking at (1.68, 1999/10/15), where problems found after the paper was published? Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
[EMAIL PROTECTED] wrote: We started losing performance with the idle page clearing so I've disabled it and haven't done much with it in quite a while. The code has fallen into disrepair and some has been removed in the latest versions. I'd suggest looking at the early 2.3.x and 2.2.1[23] series of Linux kernels. That's where it was doing its best. Thanks. I'll get that version. How do you keep track of what parts of a page are used? In Linux I was just pulling pages off the free-list and zero-ing them. Do you have a bitmap of used regions within pages on BSD? My mistake. FreeBSD zeroes the whole page as well. I traced through the code incorrectly. I wanted a few bits for each page to describe its state: zero'd, non-zero'd, busy being zero'd. It would have taken some changes to the non-arch Linux code to do that and at the time we were moving to a more stable tree so I didn't continue with it. It sounds as though you have a framework for doing that sort of thing (and more) with BSD. Can you send me a pointer to the sources you're using? I'd like to look into it. I'm running FreeBSD-stable right now, though I may switch to -current if I get promising results, to make it easier to merge. (There is a web interface to the FreeBSD CVS tree at http://www.freebsd.org/support.html#cvs). FYI, I'm interest in this for my thesis, which consists of two parts: (1) utilizing idle resources (cpu, memory, disk/network I/O, disk/memory space) for non-interfering background processing (i.e. run processes/threads using *only* idle capacities); and (2) to use that mechanism for speculative techniques. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clearing pages in the idle loop
Matt Dillon wrote: :Alan Cox wrote: : Last year, I tried to reproduce some of the claims/results : in this paper on FreeBSD/x86 and couldn't. I also tried : limiting the idle loop to clearing pages of one particular :... : : Finally, it's possible that having these pre-zeroed pages : in your L2 cache might be beneficial if they get allocated : and used right away. FreeBSD's idle loop zeroes the pages : that are next in line for allocation. : :That makes sense. Other factors that may have an impact: : : * if you always have enough zeroed pages remaining over your :benchmark ( ~1/2 free pages), FreeBSD will never do the :idle-time zeroing : : * it looks to me as if Cort's Linux code will always zero whole :pages, while the FreeBSD code is a little smarter and only zeroes :used regions of a page (less impact on caches?) : Since the only effect of a cache miss is less efficient use of the cpu, and since the page zeroing only occurs when the cpu is idle, I would not expect to see much improvement from attempts to refine the page-zeroing operation (beyond the simple hysteresis that FreeBSD uses now and perhaps being able to bypass the cache). The reason why I'm interested in Cort's results is that I'd like to extend processing in the idle loop to other things (see my other mail). Cort measured a performance decrease of foreground processing, due to polluted caches after idle-time processing. We're discussing if disabling caches during the idle loop may prevent that. The real benefit occurs on a medium-to-heavily loaded machine which is NOT cpu bound. Since nearly all page allocations require zero'd pages, having a pool of pre-zero'd pages significantly reduces allocation latency at just the time the process doing the allocation can best benefit from it. In a cpu-bound system, the idle loop does not run as often (or at all) and no pre-zeroing occurs anyway. I agree. However, on a medium-to-heavily loaded CPU, you'd probably see the largest decrease of foreground performance, as the idle times are short and bursty, and so your caches may get polluted more frequently. (Assuming cache pollution is in fact a problem; Allan seems to not think so.) If Allan still has his patches, I'll run some experiments, so we have some numbers to talk about. Maybe it doesn't matter. In regards to just zeroing the pieces of a page that need zeroing - this is NOT an optimization designed for the idle-loop page-zeroing code. I made a mistake tracing through the code. Sorry. But it may be interesting to speculate if this would speed things up. Would probably require MMU support though. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
clearing pages in the idle loop
Hello, if recently read [Dougan99], which describes optimizations to the memory management system of the PowerPC port of the Linux kernel. One of the mechanisms (Section 9) is pushing the clearing of pages to the idle task, like FreeBSD does. The authors report that on the PPC architecture, it is critical that the data and instruction cache be turned off before zeroing pages in the idle loop. Otherwise, cache pollution as a side-effect of idle-time activity would more than cancel out the gains from the zeroing. Wouldn't this be true on the i386 architecture as well? I have seen no calls in the FreeBSD idle loop that seem to do this. I'm not even sure if the i386 architecture supports turning off caches (but a quick glance at the Pentium references seems to indicate so.) Has anybody experimented with the idea before? Lars [Dougan99] Cort Dougan, Paul Mackerras and Victor Yodaiken. Optimizing the Idle Task and Other MMU Tricks. Proceedings 3rd USENIX Symposium on Operating Systems Design and Implementation (OSDI), February 1999, pp. 229-237. -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
